product:up

Table of contents

  1. Introduction
  2. How the stacks start
  3. Starting in production mode
  4. Before you start
  5. Reference
    1. Options
    2. Errors
  6. Requirements
  7. 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

product:up starts each feature stack in load order, then the product ORDER FEATURE STACKS, ONE AT A TIME LAST Load order UVL and refinements cache wait until healthy mailcatcher wait until healthy … my_first_app the product's stack Each stack has its own Compose project, the product's env file and its network
A feature that fails to start keeps the product from starting. The other features still 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) with pyproject.toml and a compose file in docker/.
  • Docker running.

See also


Back to top

splent. Distributed by an LGPL license v3. Contact us: drorganvidez@us.es