Overview
How Buildspace deploys your app — hosted git, one service per environment, and automatic env var injection.
Buildspace hosts your app straight from a Git repository. You push code; Buildspace builds it, injects the credentials your app needs, runs your database migrations, and health-checks the new release before it goes live. There is no separate hosting dashboard to configure — the repository is the source of truth for what gets deployed.
What a deploy is
Each app gets one Railway service per environment. A fresh app has a dev environment; you add prod when you roll out. The two are fully isolated — separate builds, separate databases, separate env vars.
- You push.
buildspace deploypushesHEADto the app's dev branch (buildspace/dev) on the managed Git remote. Production deploys promote a release branch instead — see the CLI docs. - Buildspace builds. The build follows your repo's
railway.json: which builder to use, the start command, the pre-deploy step, and the healthcheck path. - Migrations run. The
preDeployCommand(bun run db:migratein the starter) applies pending Drizzle migrations against the environment's database before the new release accepts traffic. Schema changes ship with the code — there is no manual migration step. - Health check gates the release. Railway hits your
healthcheckPath(/api/healthin the starter). The new release only replaces the old one once it responds. The starter's health route always returns200fast and reports database reachability in the body, so transient DB latency never flaps a deploy.
Environment variables
Buildspace injects the credentials your app needs at deploy time — you don't copy them around by hand:
| Variable | Source |
|---|---|
BUILDSPACE_DB_URL / BUILDSPACE_DB_TOKEN | Auto-injected — the managed libSQL/Turso database for that environment. |
BUILDSPACE_SECRET_KEY / NEXT_PUBLIC_BUILDSPACE_PUBLISHABLE_KEY | Your app's API keys, set once and synced to every environment. |
Add-on credentials (e.g. REDIS_URL) | Injected when you enable an add-on like Redis. |
| Your own variables | Anything you add in Creator Studio or via buildspace env. |
Server-only secrets reach the container at runtime. Browser-safe NEXT_PUBLIC_* values are inlined into the client bundle at build time — a distinction that matters when you switch to a Dockerfile build.
Next steps
- Build config — the
railway.jsonreference, and how to use a Dockerfile when you need system packages (ffmpeg, Chromium, fonts). - Redis — the optional managed Redis add-on, and the main reason to turn it on: background job queues.