Comment on page
Hostnames and rules
Customize the URLs used by each of your services for easier discovery and collaboration
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 and press Edit in the "Application Template" section.
Application Settings
In the code editor that opens, look for the
hostnames key, as shown below.
Hostname example
The default hostname looks something like this:
<service.name>-<example-app>-<env_id>-<domain>.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 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.
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 schema is shown below.
service:
type: String
required: true
description: Service name from your config
hostnames:
type: Array
required: true
description: Same as hostnames above
path:
type: String
required: true
description: Entry point for hostnames
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: rules:
- service: backend
hostnames:
- backend-${env_id}.${domain}
path: "/auth/"
- service: frontend
hostnames:
- frontend-${env_id}.${domain}
path: "/graphql"
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.Last modified 3mo ago