Each of our front web servers is applying a strict round-robin scheduling over the different containers of your application.
X-Forwarded-For: IP from the end user
X-Real-Ip: IP from the end user
X-Forwarded-Port: Either 80 or 443
X-Request-ID: UUID to identify the request, will be set if not existing
The HTTP library/framework you’re using may downcase all the header names, be cautious
Guide: Detecting HTTPS requests
If you want to have a look to those headers: here is an application which dumps them: https://http-env.scalingo.io/
HTTPS support is included by default. It is managed by application. When a custom domain name is added, our Let’s Encrypt integration will generate a valid certificate for this domain name to get valid HTTPS automatically.
Uploads - max request size
The request size limit is set to 75MB, if you’ve bigger file to upload, you should consider to use a third-party storage facility like Amazon S3 (or any other provider) and upload files directly to it (with signed-URL for instance).
Long running connections - SSE - Websockets
Long running connections and websockets are completely supported, but they are under the same constraint timeout as any other kind of request.
HTTP/2 is enabled by default for all applications. If the client supports it and is reaching the servers with HTTPS, the connection will be upgraded to HTTP/2 by our routing nodes.
Sticky session is currently only enabled for Meteor applications, it will be available as an option for any application in the future.
Your application has to accept the connection within the 30 seconds and has 30 seconds to send the first data to the client in the 30 seconds. If one of these conditions is not respected, our servers will return a 504 Gateway Timeout error to the end user.
- Connection timeout: 30s
- Read timeout: 30s
These rules also apply to the long running connections like websockets. Ensure your application is sending at least one ping every 29 seconds to keep the connection open, otherwise it will be stopped.
Each router of the infrastructure is keeping a local request queue for each
application running on the platform. For each application, this queue is
limited at 50 requests per
web container. If the queue is full and a new
request is received the router will return
503 Service Unavailable
For instance, if your application is using 2 containers of type
proxies will accept to queue up to 100 requests and will reject following
When requests are being queued, it means the application is not able to cope
with the amount of received requests, in this case, it does not worth adding
more requests to be handled. It often means your application is not well sized
compare to the traffic your instances need to handle. Either your application
should have more
web containers, or it should be optimized to respond to