Multi-Service Architecture & Cron Jobs

Learn how to configure multi-service environments with web servers, background workers, and scheduled cron jobs.

1. What is a Service in TurboV?

In real-world applications, a single codebase often runs multiple distinct workloads:

  • A public HTTP API or web frontend.
  • Background worker processes consuming Redis/RabbitMQ queues.
  • Scheduled cron tasks executing periodic cleanups or report generation.

In TurboV, an application Environment can contain multiple Services, each sharing the same underlying Git commit, environment variables, and Docker build context while running with distinct entrypoints and scaling policies.

2. Service Types

TurboV supports three native service archetypes:

                          Application Environment
                                     │
           ┌─────────────────────────┼─────────────────────────┐
           ▼                         ▼                         ▼
      [ WEB SERVICE ]        [ WORKER SERVICE ]        [ CRON SERVICE ]
  - Exposed via Traefik     - No public HTTP ports    - Runs on schedule
  - SSL & domain routing    - Continuous loop         - Cron syntax execution
  - Health check monitored  - Auto-restart on crash   - Ephemeral container

1. WEB Services

  • Exposed to incoming traffic through Traefik reverse proxy.
  • Configured with custom domains, SSL certificates, and health checks.
  • Zero-downtime blue-green deployments on updates.

2. WORKER Services

  • Background daemons (e.g. BullMQ, Celery, Sidekiq, Kafka consumers).
  • No inbound HTTP ports or domain bindings.
  • Managed with Docker restart policies (restart: unless-stopped).
  • Live logs streamed directly to dashboard.

3. CRON Services

  • Scheduled execution containers.
  • Configured with standard 5-part cron syntax (e.g. 0 3 * * * for 3
    AM daily).
  • Container spins up, executes command, logs output, and exits cleanly.

3. Configuring a Cron Job

To add a scheduled cron job to an environment:

  1. Open your application and select the target environment (e.g. production).
  2. Click Add Service → Select CRON.
  3. Configure the schedule: 
    # Execute every hour at minute 0
0 * * * *
 
# Execute every Sunday at midnight
0 0 * * 0
 
# Execute every 15 minutes
*/15 * * * *
  4. Specify the Run Command (e.g. node scripts/prune-logs.js or python -m tasks.generate_reports).
  5. (Optional) Set an execution timeout (e.g. 600s) to prevent runaway tasks from exhausting server memory.

4. Deployment Target Modes

When deploying services across multi-server environments, you can configure how services map to physical infrastructure:

Target ModeBehaviorBest For
SINGLE_SERVERService deploys to a specific designated server ID.Primary web servers, singleton cron workers, stateful apps.
TAG_GROUPService deploys to all servers possessing matching server tags (e.g. worker, high-memory, gpu).Heavy worker fleets, distributed ML queue consumers.
MULTI_SERVERService deploys across every connected server in the project.Redundant web services behind global load balancers.

5. Independent Service Controls

Within an environment, you can independently control individual services:

  • Start / Stop / Restart: Restart a single background worker without redeploying the web frontend.
  • Service Logs: Filter log streams specifically for the target service.
  • Resource Limits: Allocate custom CPU and RAM quotas per service (e.g. allocate 4GB RAM to the ML worker and 512MB to the web frontend).