App Platform scaling and release management are two sides of the same production problem: how to change capacity and application versions without creating avoidable downtime or losing rollback options.
Raff Technologies Apps currently supports service sizing, horizontal scaling, scale-to-zero, immutable revisions, rollback, workers, scheduled jobs, and preview environments.
Separate scaling from release strategy
Scaling answers:
How much capacity should run?
Release management answers:
Which application revision should receive traffic?
Do not mix them.
A bad release can fail at any scale.
A well-tested release can still fail if capacity is insufficient.
Vertical scaling changes service size
Vertical scaling increases or decreases CPU and memory per instance.
Use it when:
- one instance needs more memory;
- workload is not easily parallelized;
- operational simplicity matters.
Trade-offs:
- larger instance cost;
- possible restart/redeploy;
- single-instance failure domain remains.
Horizontal scaling changes instance count
Horizontal scaling adds more application instances.
It fits workloads that are:
- stateless;
- parallelizable;
- able to share external state.
Examples:
- web APIs;
- public web services;
- workers.
Persistent state should not live only inside one instance if multiple replicas need consistent behavior.
Scale-to-zero fits intermittent workloads
Scale-to-zero reduces idle cost when no active instance is required.
It is useful for:
- development;
- previews;
- low-frequency tools;
- bursty workloads.
Trade-off:
- cold-start latency.
Do not use scale-to-zero where immediate always-warm response is a hard requirement unless the measured cold start is acceptable.
Workers scale from queue behavior
Worker scaling should follow:
- queue depth;
- oldest-job age;
- job duration;
- CPU/memory;
- dependency limits.
Do not scale workers only from HTTP traffic.
Use Background Workers and Task Queues for SaaS Apps.
Immutable revisions simplify rollback
A release should create an identifiable revision.
A useful model is:
revision A → revision B → revision C
If C fails, rollback should reactivate B rather than rebuilding an old commit during the incident.
Raff Apps currently keeps immutable revisions and supports rollback.
Rollback does not roll back data automatically
Application rollback is easy only when data remains compatible.
A new release may:
- change database schema;
- write new queue payloads;
- create irreversible external side effects.
Use backward-compatible schema and payload changes where possible.
Zero downtime is an outcome
Zero-downtime deployment can come from:
- multiple healthy instances;
- graceful replacement;
- controlled traffic switching;
- health checks;
- compatible versions.
It is not guaranteed by a deployment button.
Use Production Deployment Strategies for SaaS Apps for the general release patterns.
Health checks should gate traffic
A new revision should not receive traffic merely because the process started.
Readiness should answer whether the application can safely serve requests.
Check:
- process started;
- required config exists;
- critical dependency connectivity works;
- application has completed warmup.
Avoid overly deep probes that turn one temporary dependency issue into total fleet removal.
Release safety needs observation
After deployment, watch:
- error rate;
- latency;
- crash/restart behavior;
- logs;
- memory/CPU;
- business events.
A deployment can technically succeed while user behavior regresses.
Preview environments reduce production risk
Preview environments let teams verify changes before merge.
They are especially useful for:
- UI changes;
- API integrations;
- database-backed flows;
- environment configuration.
They should use isolated credentials and data.
Scaling changes can hide application defects
Adding instances may reduce symptoms without fixing the cause.
Before scaling, identify whether the problem is:
- CPU;
- memory;
- slow database;
- lock contention;
- queue backlog;
- external API latency;
- poor caching.
Use scaling as a capacity response, not a substitute for diagnosis.
Capacity headroom matters during release
If a rolling replacement temporarily removes instances from service, remaining capacity must still handle traffic.
Plan release headroom separately from steady-state headroom.
Release checklist
Before production:
- revision is identifiable;
- previous revision exists;
- health checks are defined;
- database changes are compatible;
- worker payloads are compatible;
- capacity is sufficient during rollout;
- observability is active;
- rollback criteria are explicit;
- secrets/config changes are documented.
Scaling checklist
Before scaling:
- bottleneck is measured;
- state is externalized;
- service is safe to replicate;
- dependency limits are known;
- cost impact is understood;
- health checks are reliable.
Frequently asked questions
What is vertical scaling on an App Platform?
It means increasing CPU or memory per service instance.
What is horizontal scaling?
It means running more service instances in parallel.
Does scaling automatically make an application highly available?
No. Availability also depends on health checks, data services, networking, deployment behavior, and failure domains.
What makes rollback safe?
A previous immutable revision helps, but database schema, queue payloads, configuration, and external side effects must also remain compatible.
Is zero-downtime deployment guaranteed?
No. It depends on capacity, health checks, compatible versions, traffic behavior, and application architecture.
