Starting And Stopping Cloud-Local Services¶
This page describes service lifecycle for --template cloud-local
environments. For backend service management, see
Starting and Stopping Services.
Managed Services¶
The managed services are:
| Service | Component | Management |
|---|---|---|
db |
cloud |
Docker Compose (MySQL + MinIO) |
worker |
cloud |
Process (PID file) |
user_signup |
cloud |
Process (PID file) |
admin |
cloud |
Process (PID file) |
provider |
cloud |
Process (PID file) |
user |
cloud |
Process (PID file) |
The db service starts a MySQL database and a MinIO object storage instance
via docker compose. All other services are uvicorn or Python processes
managed with PID files.
Start All Services¶
The start order is:
dbworkeruser_signupadminprovideruser
If a service is already running, start logs a skip message and continues.
Start One Service¶
For db, this runs docker compose up -d db minio mc and, if present,
storage/init_storage.py from the installed cloud component.
For other services, the process is started in the background and its PID
is written to $ENV_ROOT/pids/<service>.pid.
For debugging, start a single service in foreground mode:
Foreground mode keeps the service attached to the terminal. Runtime stdout
and stderr are visible directly. --foreground cannot be used with all.
Check Status¶
Example output:
db: Running (my-cloud-db-1, my-cloud-minio-1, my-cloud-mc-1)
worker: Running (PID 12345)
user_signup: Running (PID 12346)
admin: Running (PID 12347)
provider: Running (PID 12348)
user: Running (PID 12349)
db shows the names of running Docker containers in the environment's Compose
project. Other services show their PID.
Stop All Services¶
The stop order is the reverse of the start order:
userprovideradminuser_signupworkerdb
db is stopped via docker compose down, which removes the containers.
Stop One Service¶
Process services receive TERM and are waited up to 5 seconds. db is
stopped via docker compose down.
Restart Services¶
Restart all managed services:
Restart one service:
Process Output And Logs¶
By default, runtime stdout and stderr for process services are written to:
Use --foreground when you need to inspect runtime output directly while
debugging one service.
The db service output is managed by Docker and can be viewed with: