What is a reverse proxy?
A reverse proxy is a web server that sits in front of one or more backend applications and forwards incoming requests to them. Instead of handling a request itself, the proxy passes it on to an upstream process - typically an application listening on a local port - and relays the response back to the visitor.
On TurboStack this means Nginx accepts the public HTTP/HTTPS traffic for a application and forwards it to your own application or container, rather than serving PHP-FPM or static files. It is the standard way to publish long-running application servers, such as Node.js apps, and containerized workloads, behind TurboStack's Transport Layer Security (TLS), caching and security front door.
On TurboStack
The reverse proxy is enabled per application under Configure application > Technologies > Reverse Proxy.
-
When you enable it, TurboStack generates the Nginx vhost so that requests are forwarded to your application's upstream - by default
127.0.0.1on the port you choose. -
Your application keeps running on its own port (for example a Node.js process or a Docker container), while Nginx remains the public entry point handling TLS termination and request routing.
-
It is the recommended pattern for Node.js applications such as Medusa and for Docker/containerized apps - pair it with Docker so Nginx proxies to the container's exposed port.
-
You do not edit raw Nginx config; you enable the proxy and set the upstream port (and optionally the host), and TurboStack renders and reloads the configuration for you.
Note
The reverse proxy forwards to a backend you run; it does not serve PHP. Use it when your application is its own server (Node.js, a container, a microservice), not for standard PHP sites.
Best practices
-
Bind your application to
127.0.0.1(loopback) so only Nginx can reach it, never directly from the public internet. -
Keep your app on a fixed, predictable port that matches the configured upstream port.
-
Let TurboStack terminate TLS at Nginx and proxy plain HTTP to the upstream, rather than running TLS inside the app.
-
Make sure your application starts on boot and restarts on failure, so the upstream is always available behind the proxy.
-
For containerized apps, expose a single port and proxy to it; keep one responsibility per container.