Skip to main content
This reference covers all service configuration options: templates, environment variables, resource allocation, scaling, and secrets management.

Templates

Templates are pre-configured services with production-ready defaults.
Templates search showing database options

What Templates Provide

  • Docker images with tested versions
  • Environment variables with validation and auto-generation
  • Networking and volumes configured automatically
  • Multi-service stacks with connections pre-wired

Using a Template

  1. Open the Add palette and choose Template
  2. Select a template to add to your canvas
  3. Fill required fields (passwords can be auto-generated)
  4. Customize as needed (resources, env vars, networking)
  5. Click Apply
All template settings can be modified after adding.

Multi-Service Templates

Some templates deploy complete stacks (app + database + cache) with all connections configured automatically, including service-to-service networking and shared environment variables.

Environment Variables

Environment variables configure your services at runtime.

Adding Variables

  1. Select service → Env Vars tab
  2. Click Add Variable
  3. Enter key (e.g., DATABASE_URL), value, and mark it Sensitive for secrets
  4. Click Apply

Common Variables

Accessing in Code

Node.js: process.env.DATABASE_URL Python: os.environ.get('DATABASE_URL') Go: os.Getenv("DATABASE_URL") Deno: Deno.env.get("DATABASE_URL")

Environment-Specific Values

Each environment has independent variables. Production and staging can have different database URLs, API keys, and feature flags without leaking between environments.

Resources

Resources define CPU and memory allocation per service.

CPU

CPU is set with a slider, not a fixed list of sizes. It starts at 0.05 cores and moves in steps of 0.05, up to the maximum your plan allows. See Plan Limits for the maximum on each plan. New services start at 0.1 cores. Throttling: If your service exceeds CPU allocation, it gets throttled (slowed down) but doesn’t crash.

Memory

Memory is also a slider, in steps of 8 MiB, up to your plan maximum. New services start at 128 MiB. OOM Kills: If your service exceeds memory, it will be terminated and restarted automatically.
A service killed for running out of memory loses in-memory state. Increase memory if you see this happening in logs.

CPU and Memory Ratio

On Suga Cloud, per-service memory must fall within 1 GiB to 6.5 GiB per CPU core. This is not a suggestion. A service whose CPU and memory fall outside the ratio is rejected, and you are told the valid memory range for the CPU you chose. The sliders bound themselves to the valid window, so moving CPU can move memory with it. Memory is adjusted up or down to stay inside the range. Nothing is silently rounded up behind your back.

Plan Limits

Per-service maximums and organization-wide pool budgets vary by plan. See Plan Limits for full details.

Scaling

Scale applications by adding resources (vertical) or replicas (horizontal).

Replicas

Replicas are identical copies of your service running simultaneously:
  • Load Balancing - Traffic distributed automatically
  • Redundancy - If one fails, others continue serving
  • Rolling Updates - New versions deploy gradually

Setting Replicas

  1. Select service → Config tab → Replicas
  2. Set the number of replicas
  3. Click Apply

Volume Limitation

Services with volumes can only have 1 replica. Volumes cannot be shared across instances.
Keep databases at 1 replica and scale the stateless application services that connect to them.

Cost

Replicas multiply resource costs:
  • 1 replica with 1 CPU: 1x cost
  • 3 replicas with 1 CPU: 3x cost

Common Questions

Yes, by reference. Each service owns its own variables, but a variable’s value can point at another service’s variable using {{hostname.KEY}}, where hostname is the other service’s private hostname. Suga resolves the reference when you apply, so there is one place to update the value. Set a database password once on the database service and reference it from everything that connects to it.
No, resource changes require a new deployment.
No, services with volumes must have exactly 1 replica.
Service gets throttled (slowed down) but doesn’t crash.
Service may be killed (OOMKilled) and restarted. Increase memory to prevent this.