Zuplo Platform Limits
- Applies to
- Gatewayruntime for API, AI, and MCP gateways
- Hosting
- Managed EdgeManaged DedicatedDiffersSelf-HostedNot available
1 difference by hosting option
Most limits can be customized for your instance. Contact your account team.
This document describes the limits that apply to your Zuplo account.
Managed Dedicated Environments
The limits in this document are primarily for Zuplo's managed edge environment . For managed dedicated environments and enterprise agreements, most limits are fully customizable to meet your specific requirements.
General
Below are general limits that apply to deployments on Zuplo's managed edge environments.
| Feature | Description | Limit |
|---|---|---|
| Environment Variables | The number of environment variables you can create | Free/Builder Plans: 50 variables per environment, Other Plans: 100 per environment |
| Environment Variable size | The size of an environment variable | ~5kb per variable |
| Request Duration | The maximum time a request can take to complete. See Request duration. | Free/Builder Plans: 30 seconds, Other Plans: No Limit |
| Memory | The maximum memory available when processing a request | Free/Builder Plans: 128mb, Enterprise Plans: Custom |
| Requests per second | The maximum number of requests per second | Development Environments (Working Copy): 1000 requests per minute. No Limit outside of plan monthly limit |
| Log Size | The size of a log entry | Zuplo Portal live logs are limited to ~10kB. Excess will be truncated. For third-party logging providers, the value depends on the provider. Zuplo imposes no limit. |
| Request Body Size | The maximum size of an incoming request body | 500 MB |
| Response Headers | The total size of all response headers | 128 KB |
| Subrequests | The maximum number of subrequests per request | 1,000 |
| Simultaneous Open Connections | The maximum number of simultaneous open connections per request | 6 |
Logs and tracing
Logs and tracing are included with every plan. On non-enterprise plans, log and trace ingestion is included for use within your plan's request volume. On enterprise plans, logs and tracing are included as well, though log and trace ingestion beyond typical usage may incur additional charges.
As with other features, usage is subject to "fair use" policies, meaning Zuplo may limit usage that is deemed excessive. If you require specific limits, contact sales to discuss pricing plans. Enterprise agreements govern feature availability, refer your contract for specifics.
HTTP connections
In Zuplo's managed edge environment, HTTP connections have timeouts to ensure efficient use of resources. These timeouts apply to both incoming connections from clients to Zuplo and outgoing connections from Zuplo to your origin servers.
Request duration
The request duration limit is the maximum wall-clock time a single request can take, from the moment Zuplo receives it until the response is fully delivered to the client.
| Plan | Limit |
|---|---|
| Free / Builder | 30 seconds |
| All other paid plans | No limit |
On paid plans above Builder, the request duration limit doesn't cap your requests. However, the connection timeouts below still apply, so the request duration limit isn't the only factor that determines whether a long-running request completes.
Preview and working-copy environments
The request duration limit and the connection timeouts on this page apply to all managed edge environments: production, preview (branch deployments), and working copy. Timeout behavior doesn't differ between environment types.
Working-copy environments have a separate rate limit of 1,000 requests per minute (see General). It doesn't affect request duration, but it can limit throughput during testing.
Between client and Zuplo
These timeouts measure how long an established connection between the calling client and Zuplo can remain idle (no data in either direction) before Zuplo closes it. The client's own network stack, VPN, or load balancer may impose shorter idle timeouts. If requests drop before the limits below, check for intermediate network devices that close idle connections.
| Type | Limit (seconds) | HTTP status code at limit |
|---|---|---|
| Connection Keep-Alive HTTP/1.1 | 400 | TCP connection closed |
| Connection Idle HTTP/2 | 400 | TCP connection closed |
Between Zuplo and origin server
Zuplo's managed edge environment is routed through Cloudflare's global network and is subject to the following origin connection timeouts. These timeouts govern the connection between Zuplo and your origin (backend) server, not the connection between the client and Zuplo.
| Type | Limit (seconds) | What it measures | HTTP status code at limit |
|---|---|---|---|
| Complete TCP Connection | 19 | Time to complete the TCP handshake with the origin | 522 |
| TCP ACK Timeout | 90 | Time waiting for the origin to acknowledge a TCP segment | 522 |
| TCP Keep-Alive Interval | 30 | Interval between TCP keep-alive probes on an idle connection | 520 |
| Proxy Idle Timeout | 900 | Time an established connection can sit idle with no data in either direction | 520 |
| Proxy Read Timeout | 180 | Time between consecutive data transfers from the origin (see below) | 524 |
| Proxy Write Timeout | 30 | Time to send data to the origin after the connection is established | 524 |
| HTTP/2 Pings to Origin | Off | - | - |
| HTTP/2 Connection Idle | 900 | Time an HTTP/2 connection can sit idle | Connection closed silently |
The 180-second buffered response ceiling
The proxy read timeout (180 seconds) is the limit that most often affects long-running requests. It measures the time between consecutive data transfers from the origin. The clock starts after Zuplo sends the request to the origin, and it resets every time the origin sends data, including the HTTP response headers and every subsequent body chunk.
For buffered (non-streaming) responses, your origin must begin sending the response (at minimum, the status line and headers) within 180 seconds of receiving the request. If the origin takes longer than 180 seconds to produce any output, Zuplo returns an HTTP 524 error to the client, even if your plan has a higher request duration limit.
For streaming responses, where the origin sends data incrementally, the 180-second clock restarts with every chunk, so the total request can run much longer than 180 seconds as long as data keeps flowing.
Raised duration limits don't override the proxy read timeout
If you purchased a raised request duration limit, the 180-second proxy read timeout still applies. The two limits are independent, and a request must satisfy both to complete.
Strategies for long-running requests
If your origin needs more than 180 seconds to produce a buffered response, use one of these strategies:
- Stream the response. Send data incrementally with chunked transfer encoding or server-sent events. The proxy read timeout resets with every chunk, so the origin only needs to send at least one byte every 180 seconds.
- Use an asynchronous pattern. Return an HTTP 202 (Accepted) immediately with a status URL or job identifier, and have the client poll or receive a webhook with the result. This avoids long-held connections entirely.
- Optimize the origin. Reduce processing time through caching, precomputation, or breaking large operations into smaller steps.
For more on diagnosing latency, see Troubleshooting Slow API Response Times.
Requesting a limit change
To raise the 30-second request duration limit on Free and Builder plans, upgrade to a higher plan. For custom timeout adjustments, contact sales@zuplo.com.
API keys
Consumers & keys
Zuplo doesn't impose a hard cap on the number of consumers or keys you can create. However, usage of the service is subject to "fair use" policies meaning if your usage is deemed excessive we may limit usage. If you require specific limits please contact sales to discuss pricing plans.
Our general guidelines for what constitutes fair use are as follows:
- Free Plan: 100 consumers or keys
- Builder Plan: 1,000 consumers or keys
- Enterprise Plan: Custom
Consumer metadata and tags
- Consumer
metadata- The JSON encoded object can't be larger than 1kb. - Consumer
tags- Each consumer is limited to 5 key value pair tags.
API key management operations
Requests to API key management operations on the Zuplo Developer API (dev.zuplo.com) are limited to 100 requests per second.
API key authorizations
One API key authorization can be made per request. Enterprise plans can request custom limits to allow multiple API key authorizations per request.
Cache
The cache API and abstractions on top of it such as ZoneCache have the following limits:
- Maximum size per cached item: 512 MB
- Maximum cache calls per request: 1000