NodeChef App routing overview

The NodeChef proxies, at least 3 connected to an app at any point in time recieves incomming request from your clients, terminates SSL and forwards the request to your app containers. The proxies are written in C++ and easily handles more than 30k concurrent requests per node. Our monitoring system automatically detects apps which exceed the capacity of the 3 proxies at any point in time and attaches new proxies automatically to your App. Note, this only works if you setup your DNS using a CNAME pointing to the NodeChef subdomain assigned to your app.

Routing rules

  • 1. When the proxies forward a request to your app container, it waits on a response for up to 60 seconds. If a response is not received, a 500 status is reported back to your client.
  • 2. The proxies by default enforce sticky sessions. This is a mechanism by which the proxies continues to send requests from a client to the same app container. Although this is useful for some apps. For the best load balancing performance, you may disable this feature. You can disable sticky sessions from the Task Manager by clicking on App actions → Routing. Uncheck the Sticky sessions option and click on save changes. Sticky sessions
  • 3. You can also force all connecting clients to your app endpoint to connect over TLS. The proxies accomplishes this by sending a redirect message back to the client to connect again using SSL. Typically this is handled in your application using some sort of SSL package. On NodeChef however, the proxies have this feature built in and you can enable it from App actions → Routing. Check Force SSL and click on save changes. Force SSL

Declarative features

It is possible to control URL mapping, 302 redirects , and 301 hostname redirects directly from the proxy without having to hardcode them into your App. You can access this feature from the Task manager by clicking on App actions → Routing.

  • Url Pathname routing

    Allows for routing a request to another pathname. For example, you can route any request for the pathname "/" to "index.html" or landing page static asset. The proxy will send the request to your app container using the "/index.html" path instead of the recieved "/". Note, routing does not perform a redirection. Also REGEX for more advanced URL mapping is currently not supported but planned for release in the future

  • 302 Pathname redirection

    Allows for redirecting a request to another URL. On the dashboard, the attribute name specifies the path to redirect and the value of the attribute specifies the new url to redirect to. Redirects are served using 302 Found HTTP status code

  • 301 Hostname redirection

    Allows for redirect the incoming request using the value supplied in the host header. For example, you can redirect all requests with the hostname "" to ""

  • Request forwarding

    Forward request to another container/deployment. For example you can forward all request starting with /engineering to your deployment. This feature is suitable when you want to maintain the same host name but forward the request to a different service based on the path of the incomming request.

    • An example starts with rule: /api*. The * character at the end indicates all paths that start with /api
    • An example ends with rule: */api. The * character at the start indicates all paths that ends with /api
    • An example index of rule: */api*. The * character both at the start and end indicates all paths that contain the string /api
    • An example equals to rule: /api. Will match all request where the path is equal to /api