Daily runtime commands
Use these commands in the motherrepo root after first setup. The unified runtime reads the root .env. Tmux attaches to Docker processes. It does not run a second backend stack.
Choose the action
| Goal | Command | Effect |
|---|---|---|
| Check configuration | bash devstack.sh validate | Reject invalid configuration without replacing application checks |
| Build images | bash devstack.sh build | Build the selected images. This does not establish a running healthy stack. |
| Full development start | bash startDevServers.sh | Initialize dependencies and select development execution |
| Full production start | bash startDevServers.sh --prod | Build and start compiled services |
| Stop this instance | bash stopDevServer.sh | Stop managed applications and local infrastructure, preserving volumes and keys |
| Apply configuration without a production rebuild | bash restartDevServers.sh | Recreate services with saved execution modes and current configuration |
| Select production execution | bash restartDevServers.sh --prod | Build compiled services and select production execution |
| Resume unchanged prepared containers | bash quickStarter.sh | Start stopped existing containers without build, recreation, or new configuration |
| Inspect status | bash devstack.sh status | Show services for the selected instance |
| Follow BFF logs | bash devstack.sh logs bff | Show logs. Ctrl+C ends log viewing. |
A restart preserves data but interrupts users. It does not run initialize, database-init, or schema migrations. A normal restart does not rebuild production artifacts. Development watchers can load source edits. Compiled production code requires an explicit production build. A quick start does not apply a changed .env, source selection, endpoint, password, or mode. Use ordinary restart for those changes.
Recover one service
bash devstack.sh restart bff
bash devstack.sh start bff
These commands use the service's saved mode. A scoped start with --prod explicitly selects production for that service. A scoped restart rejects --prod. See execution modes.
Check dependencies and provider selection before a scoped action. It cannot activate a provider or perform missing first-time bootstrap. In real remote mode, a local scoped command does not administer Coolify's replacement infrastructure.
Publish changed production code
For a deliberate full production release from the selected, checked source:
bash restartDevServers.sh --prod
This rebuilds production artifacts and selects production execution for the selected services. It does not replace separately required schema/dependency preparation. Review source compatibility and backups before the release.
For a scoped hotfix, use the attached-terminal procedure. A scoped restart does not build. bash devstack.sh start SERVICE --prod builds only for an already stopped, prepared service container. It refuses a running container. Do not substitute a full-stack stop for a scoped service action.
Unified production docs serve compiled static output and need a docs production build. Unified development docs run npm start, which watches source. See documentation modes.
Profiles and execution
Optional profiles select extra services. They do not change infrastructure placement. The normal setup includes FormGen and docs-mcp. Google OAuth, sync, and watch flags select their corresponding profiles. Keep provider setup complete before enabling them.
ECS_APPLICATION_SOURCE_ROOT can pin application code to a reviewed snapshot. A restart from the original checkout still uses that snapshot. Read source selection before expecting a local edit to appear.
Attach a terminal
bash devServerAttach.sh
Select the intended service. This attaches to its actual container process. Ctrl+C can stop that service. Ctrl+P, then Ctrl+Q, detaches while leaving it running. Do not start another manual process beside it.
Use bash memmonitor.sh to inspect application and container memory. It does not create more capacity. Tmux sessions and missing sessions do not establish service readiness.
Before a cold start or reset
Inspect free -h on Linux/WSL, uptime, docker ps, tmux list-sessions, and bash memmonitor.sh. On macOS, use Docker Desktop resources and Activity Monitor for memory.
Select one complete stack before cold bootstrap or destructive reset. Stop only the instance you intend to stop, from its own checkout. Preserve unrelated production containers.
resetDevServers.sh, startDevServers.sh --reset, and down -v can delete data. They are not daily recovery commands. Read the exact reset boundary before any explicitly authorized data deletion. Keep configuration, database, object-store, and encryption-key backups separately. partialRemote rejects reset and cleanup, including simulation. Do not change placement to bypass the guard.
Check the result
After startup, inspect status and the printed Account/BFF HTTPS addresses. Check login, a permitted mailbox, a body, search, and the affected feature. For writes, distinguish acceptance from provider confirmation.
If a database or another required service fails, the shared session checker throws SESSION_UNAVAILABLE. Protected API routes that use the shared authorization error converter return HTTP 503 for this error. Explicit access denials retain HTTP 401 or 403, as applicable. Check the affected service and retry the request or reload the page after the service is healthy. A database outage does not require cookie deletion, key replacement, a data reset, or another login. See service recovery for scoped runtime commands.
The shared web Prisma adapter permits one extra acquisition from the same pool after a physical new-connection timeout, before SQL. An idle connection must be visible, with no queued waiters or shutdown. It replays no SQL, request, authentication, model, or tool operation. Pool limits, timeouts, and grants stay unchanged.
DB_POOL_RECOVERY reports an attempt, at most once per pool per minute, without proof of success. Public connect can race, create a physical replacement, and cost one extra existing timeout. It does not fix the network cause. Follow the HTTP 503 recovery advice above without a reset.
For a service memory-limit failure, correct and restart that service while healthy services remain active. OOMKilled=true alone does not prove host-wide memory exhaustion. Inspect host memory and kernel evidence before treating the whole stack as affected.
See Docker reference for proxy, certificates, storage boundaries, and troubleshooting.
Exact reset boundary
This is a scope reference, not a troubleshooting procedure. The root reset path checks full-local placement and clone ownership, stops owned services, disconnects this instance's ingress from the proxy, and runs Compose down without -v. It then removes only owned volumes whose logical names are in DATA_VOLUMES:
| Removed logical volume | Data affected |
|---|---|
postgres-data | Local PostgreSQL data |
seaweedfs-data | Local file objects |
opensearch-data | Search data |
kafka-ui-data | Kafka UI state |
kafka-broker1-data, kafka-broker2-data, kafka-broker3-data | Local broker data |
kafka-connect-data | Connect state |
kafka-ksqldb-state | ksqlDB state |
flink-jobmanager-data, flink-taskmanager-data, flink-checkpoints | Flink state/checkpoints |
Other named volumes survive this reset path. Root configuration, host-local keys/certificates, shared proxy state, tunnel ownership, and other clones survive. Their survival does not replace backups. cleanup-deployment-docker.sh delegates to the same guarded reset boundary.
Bare Compose down -v is a different, broader volume-removal action. Do not substitute it for project reset. partialRemote rejects reset/cleanup before mutation, including simulation. Do not switch placement to bypass that refusal.