Standalone versus Distributed

GoForj supports standalone and distributed runtime topology.

The App code should not change when topology changes.

Standalone

Standalone hosts enabled runtimes together:

./bin/app run

Use it for:

• local development
• demos
• small deployments
• simple operational environments

Default Launch Binaries

For single-process deployments, forj build --auto-run can compile the standalone launch target into the binary:

forj build --auto-run

With that build option, launching the binary with no command starts the App runtime:

./bin/app

This is equivalent to running:

./bin/app run

Explicit commands still win. If a process supervisor starts ./bin/app api, ./bin/app worker, or any other command, the binary runs that command instead of the default launch target.

Use this when the deployment unit should behave like a normal executable service. Do not use it to hide runtime topology decisions; distributed deployments should still start explicit runtime commands.

Distributed

Distributed topology starts explicit runtime commands:

./bin/app api
./bin/app worker
./bin/app scheduler

Use it for:

• independent scaling
• separate restart policies
• scheduler singleton control
• process-specific metrics
• separate resource limits

Configuration

Topology is selected with:

RUNTIME_MODE=standalone
RUNTIME_MODE=distributed

Unknown or empty values normalize to standalone.

Common Mistakes

Common mistakes

• Do not make services depend on runtime topology.
• Do not scale scheduler processes like HTTP processes by default.
• Do not assume standalone is only for toys.
• Do not assume distributed topology makes jobs more correct without idempotency and backend planning.

Next Steps

• Runtime Topology
• Runtime Processes
• Production Checklist