Deploying services

The deploy command

conway deploy --service app --dir .

• --service names the service (default app). Deploying the same name again ships a new release.
• --dir is the source directory to upload (default the current directory).

The CLI gzips the directory (respecting .conwayignore, and always skipping .git, node_modules, .venv, …), uploads it (512MB cap), and streams the build.

How builds work

AgentCloud builds your source two ways, in priority order:

1. Dockerfile — if a Dockerfile exists at the root, it's built as-is.
2. railpack — otherwise, railpack autodetects the stack and generates a build plan. Node, Python, Go, Rust, PHP, Ruby, Java, and more are supported with zero config.

Either way the result is an OCI image pushed to the platform's internal registry and rolled out.

Examples that just work, no Dockerfile

# A Vite/React app — railpack runs the build and serves the output
conway deploy --service web

# A Flask API with a Procfile (web: gunicorn app:app --bind 0.0.0.0:$PORT)
conway deploy --service api

# A Go module
conway deploy --service svc

The health gate

After the image rolls out, AgentCloud waits up to 120s for your service to become ready on $PORT. If it never comes up, the deploy automatically rolls back to the previous release and returns HEALTH_CHECK_FAILED with the last 50 lines of your app's logs. A bad deploy never takes down a working one.

Releases & rollback

conway rollback --service app            # to the previous release
conway rollback --service app --to <id>  # to a specific release

Rollbacks are instant — they re-point the Deployment at an existing image, no rebuild.

Scaling & restarting

conway services scale app --replicas 3
conway restart app

Scaling is checked against your project quota and fails fast with QUOTA_EXCEEDED (and a hint) rather than silently wedging.

Logs

conway logs --service app -f   # follow live