product:up
Table of contents
- Introduction
- How the stacks start
- Starting in production mode
- Before you start
- Reference
- Requirements
- See also
Introduction
product:up starts your product and the Docker stacks of its features. Each feature starts in load order and must be healthy before the next one, and the product starts last.
splent product:up --dev
⏳ splent_feature_cache@v1.5.6 waiting... ✓
⏳ splent_feature_proxy ✓
⏳ my_first_app ✓
A pinned feature shows its @<version>. waiting... appears for a feature with a health check, and ✓ means its stack started and is healthy.
How the stacks start
The order is the one feature:order shows, from the UVL constraints and the refinements. The command waits up to 60 seconds for each feature’s health checks, then prints timeout and moves on. A feature without a compose file is skipped.
Each stack has its own Compose project, named after the product too, so two products of one line never share containers or volumes. Every stack reads the product’s merged env file and joins the product’s network, which is created when missing. See Features that run a server.
A pinned feature starts from its release in .splent_cache/features/, an editable one from its checkout at the workspace root.
Starting in production mode
splent product:up --prod
This runs the production image as the Compose project <product>_prod, from docker-compose.prod.yml. It is not the deployment. product:deploy runs <product>_deploy from the bundle in deploy/. Both use the same container names, so only one can run at a time, and splent product:down --prod stops both.
Without --dev or --prod, the command uses SPLENT_ENV, which must be dev or prod.
Before you start
The env file must exist, docker/.env in dev and deploy/.env in prod. When it is missing, the command says so before starting anything, and the stacks start without your product’s values.
docker/.env does not exist, so the product and its feature stacks start without this product's values: host ports fall back to whatever is free.
Run: splent product:env --merge --dev
Once every feature is up, the command writes SPLENT_ENV into docker/.env. A failed run leaves it untouched.
Reference
Options
| Option | Description |
|---|---|
--dev |
Start development, from docker-compose.dev.yml or docker-compose.yml |
--prod |
Start the production image as <product>_prod, from docker-compose.prod.yml or docker-compose.yml |
Errors
| Message | What to do |
|---|---|
N service(s) failed to start: <names> |
The failing features show ✗ and the error. The other features started, the product did not. Fix them and run it again |
Could not resolve the feature load order: |
A warning. The stacks start in declared order |
<feature>@<version> is not in .splent_cache, ... |
The workspace checkout is used instead. Run splent product:resolve |
No Docker Compose file found for <product> (<env>). |
Add docker/docker-compose.<env>.yml or docker/docker-compose.yml |
Unknown environment '<env>'. |
Pass --dev or --prod, or set SPLENT_ENV to dev or prod |
pyproject.toml not found in product path. |
Run it on a product |
Requirements
- A selected product (
SPLENT_APP) withpyproject.tomland a compose file indocker/. - Docker running.
See also
product:downstops what this starts.product:runruns the entrypoint once the stacks are up.