> 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/guides-and-examples/advanced-guides/hostnames-and-rules.md). # Hostnames and rules Customize the URLs used by each of your services for easier discovery and collaboration ## Hostnames Each public service in each environment has a unique hostname that can be built from components, including: * The service name (for example, "frontend") * The application name (for example, "voting app") * The environment ID (for example, "production" for a permanent environment or "ted8a14" for an ephemeral environment) * Your domain (for example, example.com or .rls.sh) Configure your hostnames in the Application Template file. For example, you might want longer hostnames to make it easier to identify from the name exactly which application and environment you're viewing, or shorter hostnames for easier readability and sharing. To change the default hostname for an application, navigate to the **Settings** tab for the application. Look for the `hostnames` key, as shown below. ![Look for the hostnames key](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-f3bcdb9c80b0e82c6dd79bff8004b10e887b2135%2Fapplicaton-settings-hostnames.png?alt=media) The default hostname looks something like this: `---`. The hostname starts with the service name followed by the application name (for example, `frontend-voting-app`), then a unique random environment ID (for example, `ted1bc4` for an ephemeral environment or `production` for a permanent environment), and finally, your domain name (for example, `example.com`). A service called "frontend" that is part of an application called "voting-app" running in an environment with the ID "ted1bc4" on the free tier of Release would look like this: `https://frontend-voting-app-ted1bc4-.rls.sh`. You can customize your hostname by adding hard-coded strings or by adding or removing the available templated variables. For example, if you don't want the environment ID in the hostname, you can change the template string in the Application Template file to `frontend-voting-app.${domain}`. Click **Save as new version** and the next time you deploy, you'll see the updated custom hostname. Note that customizing the hostname URL in the default Application Template file will affect the default hostname of every other environment that is instantiated from this global default. If you have a starter account, you will need to leave the domain variable in place so that you can view your environments on the `rls.sh` domain. ## Rules Rules provide an alternative way to define entry points to your services and let you assign multiple endpoints for a single service. Rules are based on the [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/user-guide/basic-usage/). When you define rules in your Release configuration, Release will automatically set up an NGINX Ingress deployment to handle routing for you. Rules consist of a **service**, one or more **hostnames**, and a **path**. The full schema is shown [here](/reference-documentation/application-settings/application-template/schema-definition.md#rules-1). As an example, you could set up the following rules for an application with a backend authentication system served from `/auth/` and a frontend GraphQL server from `/graphql` using the following rules: ```yaml rules: - service: backend hostnames: - backend-${env_id}.${domain} path: "/auth/" - service: frontend hostnames: - frontend-${env_id}.${domain} path: "/graphql" ``` You could also "mix and match" visibility rules which allow you to host private URLs: 
 rules:
  - service: backend
    hostnames:
    - backend-${env_id}.${domain}
    path: "/"
    visibility: public
  - service: admin
    hostnames:
    - admin-${env_id}.${domain}
    path: "/"
    visibility: private
## Choosing between hostnames and rules If you only want to configure how your hostnames look and behave, changing the hostname template is the simplest option. Use rules for more complicated cases, such as when you need to assign more than a single endpoint to a specific service. Note that you can't use both hostnames and rules at the same level of your configuration. For example, you cannot define both rules and hostnames in your default Application Template file, but you can define default hostnames and then override them with rules inside the `environment_templates` section. --- # 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/guides-and-examples/advanced-guides/hostnames-and-rules.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.