Documentation

Large service workspace

Keep a large service list readable with shared conventions and global defaults.

When to use this

Use this pattern when a monorepo has many local services but they all follow the same launcher convention. The goal is to make the process list boring and predictable.

Example

[global]
log_mode = "both"
log_format = "json"
env_file = ".env"
before = ["./tools/prebuild-services.sh"]

[global.readiness]
type = "log"

[global.readiness.ready]
pattern = "service_ready"

[global.log_template]
stdout_preset = "rust"
stderr_preset = "rust"

[[process]]
name = "billing-public"
command = "./tools/run_service.sh billing-public"

[[process]]
name = "billing-grpc"
command = "./tools/run_service.sh billing-grpc"

[[process]]
name = "billing-worker-rollup"
command = "./tools/run_service.sh billing-worker-rollup"

[[process]]
name = "iam-public"
command = "./tools/run_service.sh iam-public"

[[process]]
name = "iam-grpc"
command = "./tools/run_service.sh iam-grpc"

[[process]]
name = "iam-outbox-worker"
command = "./tools/run_service.sh iam-outbox-worker"

[[process]]
name = "notifications-email-send"
command = "./tools/run_service.sh notifications-email-send"

[process.log_template]
stdout_preset = "email"
stderr_preset = "email"

Why this works

The file stays readable because most behavior is global:

  • one launcher convention
  • one shared env file
  • one readiness signal
  • one default log template

Individual process entries only declare the stable name and command. Exceptions stay local, such as the email-specific log template.

Defaults involved here

  • instances: default 1
  • process.readiness: inherits global.readiness
  • process.log_template: inherits global.log_template
  • process.log_mode: inherits global.log_mode
  • process.log_format: inherits global.log_format
  • show_timestamps: effective default true

What to customize

  • Choose a launcher convention that every service can use.
  • Keep process names stable; they become restart targets, status rows, and log identifiers.
  • Use global settings for common behavior.
  • Keep exceptions explicit and close to the process that needs them.
  • Add groups for TUI organization and labels for cross-cutting startup filters.

See also