Docs/Deploying

Deploying

How Launchmatic builds and deploys your code, from git push to live URL.

Build pipeline

Every deployment follows the same pipeline:

CloneLaunchmatic clones your repository at the specified branch and commit SHA.

DetectThe runtime detector scans your project files (package.json, requirements.txt, go.mod, Cargo.toml, Dockerfile) to determine the runtime and framework.

BuildA container image is built using your Dockerfile or an auto-generated one based on your detected runtime. Build logs stream in real time.

PushThe image is pushed to the internal container registry (or your configured Artifact Registry).

DeployA Kubernetes Deployment is created (or updated) with your image, env vars, port, and resource limits. Traffic is routed via the ingress proxy.

Runtime detection

Launchmatic inspects your project root for known config files:

File	Runtime
package.json	Node.js
requirements.txt / pyproject.toml	Python
go.mod	Go
Cargo.toml	Rust
Gemfile	Ruby
index.html	Static
Dockerfile	Docker (custom)

If a Dockerfile exists it always takes priority. Otherwise Launchmatic generates one based on the detected runtime.

Custom Dockerfiles

Place a Dockerfile in your project root for full control. Launchmatic will use it as-is. Make sure your Dockerfile exposes the correct port and runs a process on startup.

Monorepos: when your Dockerfile lives in a subdirectory but the build context must be the repo root (so workspace files like pnpm-lock.yaml are reachable), set the Dockerfile Path field in Service settings to e.g. apps/web/Dockerfile. From the CLI:

lm deploy --dockerfile apps/web/Dockerfile

In a multi-service repo with a launchmatic.json manifest, lm monorepo init auto-detects a Dockerfile at <rootDir>/Dockerfile for each service and persists the path. Editing the manifest's dockerfile entry takes effect on the next lm up.

Pre-deploy (release phase)

Set a Pre-deploy Command on a service to run a one-shot task with the freshly-built image before any pod rolls out — the standard pattern for database migrations. The command runs in a Kubernetes Job with your service's env vars (so DATABASE_URL etc are present), its pod logs are appended to the deployment's build logs under a ── Pre-deploy ── divider, and failure aborts the deploy. No traffic shifts unless the pre-deploy step succeeds.

Stack	Pre-deploy command
Prisma	npx prisma migrate deploy
Drizzle	npx drizzle-kit migrate
Knex	npx knex migrate:latest
Rails	bundle exec rails db:migrate
Django	python manage.py migrate --noinput
Alembic / FastAPI	alembic upgrade head
Goose (Go)	goose -dir migrations postgres $DATABASE_URL up

lm deploy --pre-deploy-cmd "npx prisma migrate deploy"

Skipped for preview deploys (they share the production database and rerunning migrations per PR is rarely what you want).

Build logs

Every deployment captures its build output (runtime detection, Dockerfile selection, Kaniko output, npm/pip install lines, etc.) and the pre-deploy phase if one ran. From the CLI:

lm logs --build                          # latest deployment
lm logs --build --service api            # monorepo: pick by name
lm logs --build --deployment <id>        # specific deployment

Output starts with the deployment id, status, commit, and branch so it's paste-ready when reporting issues. In the dashboard the same logs appear under any deployment's Build Logs tab.

Rollbacks

Every deployment is immutable. To roll back, click the “Redeploy” button on any previous successful deployment. Launchmatic will re-deploy that exact image and config.

Scale to zero

Idle services are automatically scaled to zero replicas after a configurable inactivity period (default: 30 minutes). When a request arrives, the proxy wakes the service within seconds. This keeps costs minimal for staging and hobby projects.