Processes and Scaling

Most production apps are more than one web process. Watasu treats every named process in your Procfile as a separately scalable workload, and the name decides what kind of routing it gets.

What a process is

A process is one named workload inside an app. The process name carries meaning — Watasu reads the suffix to decide how to expose it:

Pattern	Routing	Common use
`web`, `*-web`	Public HTTP/WebSocket with managed TLS	Main app, admin UI, public API
`*-tcp`	Private TCP, reachable only by trusted apps	Internal gRPC, RPC, internal APIs
`*-rtc`	Public UDP via per-process TURN gateway	WebRTC, SFUs, voice agents
`release`	Runs once per deploy, before rollout	Migrations, one-time per-release setup
Anything else (e.g. `worker`)	Not reachable from the network	Background jobs, schedulers

So web, admin-web, api-web, grpc-tcp, sfu-rtc, worker, and release aren’t naming conventions — they’re the routing contract.

See Private Networking for *-tcp and Real-Time and WebRTC for *-rtc.

Multiple public web processes

You’re not limited to one web process per app. Name additional public entrypoints with the *-web suffix and Watasu routes each one publicly:

web:        bundle exec puma -C config/puma.rb
admin-web:  bundle exec puma -C config/admin_puma.rb
api-web:    bundle exec puma -C config/api_puma.rb
worker:     bundle exec sidekiq

Each *-web process gets its own managed *.watasu.app URL, scales independently, and can have its own custom domain attached:

watasu domains:add admin.example.com --process admin-web --app my-app

This is how you keep an admin surface, a public API, and your main app in one codebase without splitting into three deployments.

The release process

A process named release runs once per deploy, before the new release goes live. Use it for:

database migrations
one-time per-release setup checks
cache invalidation or priming
assets compilation that can’t happen in the build

release: bundle exec rails db:migrate
web:     bundle exec puma
worker:  bundle exec sidekiq

A failing release process aborts the deploy — the new code never goes live. Keep release tasks fast and idempotent.

Inspect the formation

watasu pods --app my-app

Shows each process type with its replica count, pod size, CPU/memory, and routing.

Scale replicas

watasu pods:scale web=3 worker=1 --app my-app

Each process scales independently. Set a process to 0 to stop it without removing it from your Procfile.

Change pod sizes

watasu pods:type web=standard-2x worker=standard-1x --app my-app

Available sizes run from standard-1x to standard-16x. Larger sizes mean more CPU and memory per replica. See Pod Sizes for the full table.

Scale out vs. scale up

There are two levers and they solve different problems:

Scale out (more replicas) when concurrency is the bottleneck — many short requests, parallel job consumption, fault tolerance.
Scale up (bigger pods) when a single process is memory- or CPU-bound — large in-memory caches, single-threaded hot paths, image processing.

A common starting formation for a real app:

watasu pods:scale web=2 worker=1 --app my-app
watasu pods:type web=standard-1x worker=standard-1x --app my-app

Two web replicas give you redundancy. Worker is separate so a slow background job doesn’t stall HTTP requests.

Multi-DC placement

Once a process is scaled to 2 or more replicas, Watasu automatically spreads them across two German data centers (Nuremberg and Falkenstein) for resilience — no configuration needed.

Scaling is a runtime change

Scaling and pod-type changes are immediately applied to running pods. Treat them like deploys:

change one thing at a time when you’re debugging
watch logs and metrics afterwards
prefer additive changes (scale up first, scale old down second) for sensitive workloads