Deployment and hosting

In development. 86d is being built in the open. Every capability is Experimental until it earns evidence, so check maturity levels before you rely on anything here.

86d.store ships with a Dockerfile and a docker-compose.yml, and it runs on Railway or Vercel without modification. Pick the tab that matches where you want it. All three paths are you hosting a Store Runtime yourself, which means you also own the database, the backups, and the uptime. Those host names appear here only because you chose them. A deployment created through 86d.app is a different arrangement: 86d provisions the machines, runs the deployment, and bills you as a Managed Deployment. That path never names the suppliers behind managed hosting, DNS, or payments. You operate 86d Cloud. See 86d Cloud plans and architecture.

Docker (self-hosted)
Railway
Vercel and Neon

Compose starts PostgreSQL 16, MinIO object storage, and the Store app. Copy the environment template:

cp .env.example .env

Generate an auth secret:

openssl rand -base64 32

Put the printed value into .env, replacing the placeholder:

.env

BETTER_AUTH_SECRET=replace_with_generated_value

Then start it:

docker compose up

Run a release image

Once an operator publishes a release, pull the immutable version tag for the 86d.store Store Runtime image from either registry:

docker pull ghcr.io/86d-app/store:VERSION
# or
docker pull docker.io/86dapp/store:VERSION

Replace VERSION with the exact release version. Start the selected image with the same PostgreSQL, storage, and Store services without rebuilding source:

STORE_IMAGE=ghcr.io/86d-app/store:VERSION docker compose up -d --no-build
# or
STORE_IMAGE=docker.io/86dapp/store:VERSION docker compose up -d --no-build
curl --fail http://127.0.0.1:3000/api/health

The release path promotes latest only after both immutable registry tags resolve to the same multi-platform image. Pin a version or digest for a production deployment because latest moves on the next release.First boot waits for PostgreSQL, applies internals/docker/init.sql (nanoid/pgcrypto), runs Drizzle migrations, compiles curated Module tables, seeds demo data with AUTO_SEED=true, and starts the Next.js server on port 3000. Seed writes only curated Modules that compile to tables (stripe remains tier-none). A second container restart with AUTO_SEED=true must upsert the same seed-owned keys without wiping schemas or duplicating rows.Health is served at /api/health after boot. Four services come up:

Service	Default port
Store app	3000
PostgreSQL	5432
MinIO API	9000
MinIO Console	9001

Compose sets NODE_ENV=production. In production the runtime rejects a placeholder secret, a known default, anything shorter than 32 characters, and anything with too little entropy, so the app will not start until you paste a real value. Paste the output of openssl, not the command itself.Uploads go to MinIO by default and are served from your own origin at /uploads/..., so the bucket never has to be public.Port conflicts are overridable:

POSTGRES_PUBLISH_PORT=5433 \
STORE_PUBLISH_PORT=3001 \
MINIO_API_PUBLISH_PORT=9002 \
MINIO_CONSOLE_PUBLISH_PORT=9003 \
docker compose up

Railway runs the Store as a container and gives you managed PostgreSQL. Use the Deploy on Railway button on the GitHub repository.Two variables are required:

Variable	Where it comes from
`DATABASE_URL`	Filled in by Railway when you attach a PostgreSQL service
`BETTER_AUTH_SECRET`	You generate it with `openssl rand -base64 32`

Set BETTER_AUTH_SECRET under Variables before the first deploy, or the container will not boot.For uploads, add a Railway object storage bucket and set:

STORAGE_CLIENT=s3
S3_ENDPOINT=https://railway-bucket-endpoint.example
S3_BUCKET=store-assets
S3_ACCESS_KEY=your_access_key_here
S3_SECRET_KEY=your_secret_key_here
S3_VIRTUAL_HOSTED_STYLE=true

Railway sets RAILWAY_PUBLIC_DOMAIN at runtime, so you can write APP_URL=https://$RAILWAY_PUBLIC_DOMAIN instead of hardcoding the hostname.

Vercel hosts the Next.js app and Neon supplies PostgreSQL. Use the Deploy on Vercel button on the GitHub repository.

Variable	Value
`DATABASE_URL`	Neon pooled connection string
`DATABASE_URL_UNPOOLED`	Neon direct connection string, used for migrations
`BETTER_AUTH_SECRET`	`openssl rand -base64 32`
`STORAGE_CLIENT`	`vercel`
`BLOB_READ_WRITE_TOKEN`	From your Vercel Blob store
`VERCEL_BLOB_STORAGE_HOSTNAME`	Your Blob store’s public hostname

Neon hands you two connection strings. The pooled one is for the app and the direct one is for migrations. Using the pooled string for migrations fails in ways that are hard to read, so set both.

Variables you will actually set

The full list is in Environment variables and in .env.example. These are the ones every deployment needs:

Variable	Required	What it does
`DATABASE_URL`	Yes	PostgreSQL connection string
`DATABASE_URL_UNPOOLED`	Yes	Direct connection string, used for migrations
`BETTER_AUTH_SECRET`	Yes	Signs sessions. Generate with `openssl rand -base64 32`
`STORE_ID`	Recommended	Data isolation boundary for a standalone Store. Defaults to a fixed development UUID if unset
`STORAGE_CLIENT`	No	`local`, `vercel`, or `s3`. Defaults to `local`
`APP_URL`	No	Your Store’s public URL, for example `https://example.com`

Values 86d Cloud supplies

A Managed Deployment receives 86D_STORE_ID, 86D_API_URL, and 86D_WORKLOAD_CREDENTIAL together. The runtime trades the opaque credential at the Control Plane for short-lived, Store-scoped access before it fetches any managed configuration. The credential can be rotated and revoked, it carries no provider secrets, and it cannot authenticate a person. Do not set these on a Store you host yourself. Standalone Stores use STORE_ID for local data isolation and read their configuration from the active Template. Human sign-in to a managed Store Admin uses a separate pair, 86D_ADMIN_OAUTH_CLIENT_ID and 86D_ADMIN_OAUTH_CLIENT_SECRET. Keep every machine credential and client secret out of browser code, logs, agent output, Templates, and Store Admin settings. See managed identity.

Where uploaded files go

STORAGE_CLIENT decides where Product images, PDFs, and other uploads live.

Value	Use it for	Also set
`local`	Local development, self-hosted Docker	`STORAGE_LOCAL_DIR` (default `./uploads`)
`vercel`	Vercel deployments	`BLOB_READ_WRITE_TOKEN`, `VERCEL_BLOB_STORAGE_HOSTNAME`
`s3`	MinIO, AWS S3, Cloudflare R2, Railway buckets	`S3_ENDPOINT`, `S3_BUCKET`, `S3_REGION`, `S3_ACCESS_KEY`, `S3_SECRET_KEY`

local writes to the container filesystem. On Vercel and other stateless hosts every deploy wipes it, which means your Product images disappear. Use vercel or s3 there.

Configure storage has the per-provider detail.

Before you point a domain at it

Work through this list after the first deploy and before anyone can reach the Storefront:

Replace the seeded Store Admin password
Confirm BETTER_AUTH_SECRET is a random value, not the placeholder
Set APP_URL to the public domain
Configure one sandbox payment provider and its webhook verification values, per Payment integrations
Upload a Product image in Store Admin to prove storage works
Run 86d doctor and clear every failure

Finishing that list does not make this release safe for real money. No Checkout, Payment, tax, Shipping, Inventory, or webhook path has recorded evidence yet. Read Versioning and maturity before you accept an Order from a stranger.

Get started

Concepts

Configuration

Guides

CLI

Operations

Resources

Deployment and hosting

Run a release image

Variables you will actually set

Values 86d Cloud supplies

Where uploaded files go

Before you point a domain at it

​Run a release image

​Variables you will actually set

​Values 86d Cloud supplies

​Where uploaded files go

​Before you point a domain at it

​Related pages

Run a release image

Variables you will actually set

Values 86d Cloud supplies

Where uploaded files go

Before you point a domain at it

Related pages