Skip to main content

Development and production execution

Development execution watches application source. Production execution uses compiled output. These modes are separate from local or remote infrastructure placement.

The runtime saves successful execution modes per service. A normal restart resumes them without rebuilding production artifacts or running schema initialization. Use the production publication procedure for compiled code changes. quickStarter.sh resumes existing stopped containers without a build or mode change.

Use service execution modes for exact command behavior. For a new machine, use first installation.

Change local or remote placement​

For an existing installation, use the placement switch procedure. It covers the return from partialRemote to fulllocal, retained Kafka/Qdrant data, and endpoint checks. Use ordinary restart after a placement change. Quick-start resumes only unchanged, prepared containers.

Keep the local volumes and check their freshness before returning from remote services. A placement switch does not transfer remote writes into retained local data. Do not use reset or volume deletion for this change. For the remote direction, use selected remote infrastructure.

Accept the installation only after all four lifecycle scripts succeed: start, restart, stop, and quick-start. Follow the lifecycle acceptance checks during an agreed maintenance window. Check the running consumers' selected endpoints and existing application data after resume. A healthy service or mode label alone does not prove the selected placement.

Preserve the isolated runtime owner marker​

Before a source refresh, check the isolated instance's .docker-state/owner identity separately from its file permissions. For this maintenance, require a physical file owned by the operator, with permissions 0600.

Only repair permissions on a verified, stopped, owned isolated instance. Preserve the marker content and instance identity. Preserve all environment files, keys, and data. Refuse the repair if ownership or identity is uncertain. Do not modify another clone's marker or copy its runtime state.

These are operator safeguards. The runtime checks marker identity, but it does not automatically enforce the marker's 0600 permissions or operator ownership. The isolated snapshot checks reject symbolic and hard links. A permission repair must leave the identity unchanged.