> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/reference-documentation/networking/ingresses.md). # Ingresses An *ingress* is the main point of entry to your cluster from the public internet. By default, Release configures an Nginx ingress for your cluster, and in many cases, you can use it with the default settings. For advanced cases, you can configure your ingress in your Application Template file, along with your other environment settings. Some common cases where you might need to configure your ingress manually include: * Setting specific cookie configuration, such as expiration times. * Setting affinity sessions or "stickiness" to ensure visitors are predictably served by the same nodes. * Changing the default buffer sizes and timeout parameters to serve larger files. ## Sticky sessions and affinity Usually, incoming requests are served by any available node. This means that subsequent requests by the same visitor might be served by different nodes. For many applications, this doesn't matter, as all nodes are running exactly the same application code. If you perform A/B testing or are rolling out a feature gradually to all users, it might be important that users have a consistent experience, even across multiple visits. In these cases, you can configure *affinity* in your ingress settings. This creates a pairing between unique visitors and specific nodes by setting a random cookie for each new visitor. Returning visitors will automatically share the cookie along with their request, and your ingress will direct them to the same node they were previously served by. In the diagram below, the visitor automatically sends the previously randomly generated cookie on their second visit, allowing the ingress to say they should be served by node 1 again. ![Affinity cookie](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-0b01ae818e242ae64a652faac8db7a54a49cbc10%2Faffinity.png?alt=media\&token=ae43a0c6-95dc-4945-aeaf-356ec56f6a9f) You can customize exactly how specific situations are handled by setting `affinity_mode` to either `balanced` or `persistent`. If you are too strict about always assigning users to specific nodes, you can lose the advantages of running a cluster in the first place. For example, the node might be down or overloaded. By using `balanced`, some users might be reassigned to other nodes if the cluster is scaled up. By using `persistent`, users will always be given their assigned node until the cookie expires. An example of setting up your ingress with cookie-based affinity is shown below, which will ensure that all users are served by the same node for 24 hours. If a request fails, then the affinity will be ignored and the user will be served by a healthy node. ```yaml ingress: affinity: "cookie" affinity_mode: "persistent" session_cookie_name: "custom-cookie-name" session_cookie_path: "/" session_cookie_max_age: 86440 session_cookie_change_on_failure: true ``` You can read more about how Kubernetes handles affinity in their [affinity docs](https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/). ## Buffer settings and large web requests By default, the ingress is optimized to serve many smaller files to many different users. This works well for most web applications that consist of many pages and other resources such as JavaScript, CSS, and images. If your application serves larger files, you'll probably want to configure the ingress buffers and timeouts. With larger buffers, the ingress will do more of the work, buffering data received from the application. This means that you can serve your users in fewer total requests, but with the tradeoff of putting more stress on the hardware responsible for your ingress. An example of an ingress configured to serve larger web requests is shown below. ```yaml ingress: proxy_body_size: 30m proxy_buffer_size: 64k proxy_buffering: true proxy_buffers_number: 4 proxy_max_temp_file_size: 1024m proxy_read_timeout: "180" proxy_send_timeout: "180" ``` This creates a larger temporary file, so that the ingress can store data locally even if the buffer sizes are exceeded. It also sets longer timeouts of three minutes, and creates more buffers to read the initial parts of the response from the application servers. You can find the full schema definition for configuring ingresses [in the schema docs](/reference-documentation/application-settings/application-template/schema-definition.md#ingresses). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.release.com/reference-documentation/networking/ingresses.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.