Each deployed app consists of two services: an app service that serves the web application and API, and a worker service that executes background workflows. Both are independently configurable.
App service
| Setting | Default | Description |
|---|
| CPU | 0.5 vCPU | CPU allocated per instance |
| Memory | 2048 MB | Memory allocated per instance |
| Min instances | 1 | Minimum running instances |
| Max instances | 10 | Maximum running instances |
| Scale-out cooldown | 60s | Wait time before adding another instance |
| Scale-in cooldown | 300s | Wait time before removing an instance |
| Request count target | 1000 req/min | Requests per minute per instance before scaling out |
| CPU utilization target | 70% | CPU threshold before scaling out |
Apps run on Node.js and handle requests asynchronously on a single-threaded event loop. Most request processing is I/O-bound — database queries, service calls, and API requests to third-party services — while CPU-intensive work is typically offloaded to the worker service. The default settings are suitable for most internal and moderate-volume workloads. For high-availability or high-traffic apps, or apps expecting large bursts in traffic, the minimum and maximum instance counts can be adjusted accordingly.
Worker service
Task settings
| Setting | Default | Description |
|---|
| CPU | 0.5 vCPU | CPU allocated per instance |
| Memory | 4096 MB | Memory allocated per instance |
| Temporary disk | 21 GB | Disk storage per instance (21–200 GB) |
| Min instances | 1 | Minimum running instances (0 to scale to zero) |
| Max instances | 10 | Maximum running instances |
| Target demand | 50% | Scaling target as a percentage of max concurrency — see Autoscaling |
| Scale-out cooldown | 60s | Wait time before adding another instance |
| Scale-in cooldown | 300s | Wait time before removing an instance |
Workflow settings
| Setting | Default | Description |
|---|
| Max concurrency | 4 | Maximum concurrent workflow executions per instance |
| Max parallel steps | 1 | Maximum steps executing in parallel within a workflow |
| Poll interval | 5000 ms | How often the worker polls for new work |
| Default TTL | 48 hours | How long workflow step data is retained |
| Max query rows | 10,000 | Maximum rows returned when querying workflow step results (e.g., via the admin UI or API) |
| Default max duration | 1440 min (24h) | Maximum execution time for a single workflow |
The default settings are tuned for general-purpose data processing and asynchronous workflows, and are suitable for most workloads. Apps with data-intensive workflows — large datasets, complex transformations, or heavy file processing — benefit from increased worker memory and CPU, which also proportionally increases the resources available to each step. Apps with high workflow volume benefit from increasing max concurrency and max parallel steps to process more work simultaneously across fewer instances.
Step resource limits
Each workflow step runs with its own resource allocation for data processing:
| Setting | Default | Description |
|---|
| Step memory limit | 768 MB | Memory limit for data processing operations per step |
| Step spill limit | 4 GB | Disk spill limit for data processing operations per step |
| Step threads | 1 | Thread count for data processing operations per step |
Step resource limits are automatically derived from the worker task settings and are not directly configurable. Increasing worker CPU and memory will proportionally increase the resources available to each step.
Valid CPU and memory combinations
CPU and memory must be configured in supported pairings:
| CPU | Memory |
|---|
| 0.25 vCPU | 512 MB, 1 GB, 2 GB |
| 0.5 vCPU | 1 GB, 2 GB, 3 GB, 4 GB |
| 1 vCPU | 2–8 GB (1 GB increments) |
| 2 vCPU | 4–16 GB (1 GB increments) |
| 4 vCPU | 8–30 GB (1 GB increments) |
| 8 vCPU | 16–60 GB (4 GB increments) |
| 16 vCPU | 32–120 GB (8 GB increments) |
Database
Each app gets a dedicated serverless Postgres database that scales automatically based on demand.
Synthetiq Hosted
| Setting | Default | Description |
|---|
| Min compute | 0 | Minimum compute units (0 to suspend when idle) |
| Max compute | 2 | Maximum compute units to scale to |
| Suspend timeout | 5 minutes | Time idle before the database suspends |
When min compute is set to 0, the database suspends automatically after the idle timeout and resumes near-instantly on the next connection. For customer-facing or high-availability apps, min compute can be configured above 0 to eliminate cold starts entirely.
Bring Your Own Infrastructure (AWS)
| Setting | Default | Description |
|---|
| Min capacity | 0.5 | Minimum capacity units |
| Max capacity | 2 | Maximum capacity units to scale to |
BYOI (AWS) does not natively support database scale-to-zero. The database remains running at the minimum capacity at all times. For customer-facing or high-throughput apps, increase the max capacity accordingly.
