Hostnames and rules
You can 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 (e.g. "frontend")
- The application name (e.g. "voting app")
- The environment ID (e.g. "production" for a permanent environment or "ted8a14" for an ephemeral one)
- Your domain (e.g. example.com, or .rls.sh)
You can configure your hostnames in the Application Template file. For example, you might want longer hostnames to make it easier to identify exactly which application and environment you're viewing, just from the name, or have shorter ones for easier readability and sharing.
To change the default hostname for an application, navigate to the "Settings" tab for that application and press "Edit" under "Application Template".
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>.It starts with the service name, followed by the application name (e.g. frontend-voting-app). Then it has a unique random environment ID (e.g. "ted1bc4" for an ephemeral environment or "production" for a permanent environment), and ends with your domain name (e.g. example.com).
As a full example, a service called "frontend" that is part of an application called "voting-app" running in an environment with ID "ted1bc4" running 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 could 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, and when you define rules in your Release configuration, Release will automatically set up an NGINX Ingress deployment for you, which will handle routing.
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 your simplest option. You should 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 could define default hostnames and then override these with rules inside the
environment_templates section.Last modified 3mo ago