--- url: https://docs.hostly.ninja/concepts/domains-and-domain-fragments.md --- # Hostly Domains and Domain Fragments Hostly uses domains to address workspaces and services uniquely on the internet. ## DNS in brief The **Domain Name System**, or DNS, translates readable domain names into technical network and routing information. When a user opens `app.example.hostly.ninja`, DNS first ensures that the request reaches the Hostly infrastructure. Hostly then maps the request to the matching service and forwards it there. No custom DNS records are required for domains provided by Hostly. Everything is fully configured and ready to use from the moment the service is deployed. ## Four central terms | Term | Example | Meaning | |---|---|---| | Workspace domain fragment | `example` | The name part assigned to a workspace. | | Workspace domain | `example.hostly.ninja` | The full domain of the workspace. | | Service domain fragment | `app` | The name part assigned to a service. | | Service domain | `app.example.hostly.ninja` | The publicly reachable domain of the service. | The service domain always follows this pattern: ```text ..hostly.ninja ``` ## Workspace domain fragment The workspace domain fragment is globally unique. Therefore, only one workspace worldwide can use, for example, `example` or `example.hostly.ninja`. An account with multiple workspaces needs its own globally unique workspace domain fragment for each workspace. The workspace and its domain fragment currently cannot be renamed. ## Service domain fragment The service domain fragment must be unique within the workspace. Example: ```text app.example.hostly.ninja api.example.hostly.ninja status.example.hostly.ninja ``` Another workspace may use the same service domain fragments: ```text app.data.hostly.ninja app.example.hostly.ninja ``` A service may also use the same fragment as its workspace: ```text example.example.hostly.ninja ``` Hostly always creates exactly one additional domain level for the service. ### Service domain fragment and service name The service domain fragment is not the same as the [service name](./service.md#service-name). The service domain fragment determines the public address and can be changed. The service name determines the internal address `:` and can never be changed. When creating a service, the wizard prefills the service name from the service domain fragment. ### Services without domain Internal services have no service domain and therefore no service domain fragment. They are only reachable by other services of the workspace via their service name. See [What is a Service?](./service.md#internal-services). ## Character rules The following characters are currently allowed for workspace and service domain fragments: ```text Alphanumeric: a-z, 0-9 ``` Uppercase letters are automatically converted to lowercase. Service names follow [their own rules](./service.md#service-name) and may also contain hyphens. ## Changes and reservation The workspace domain fragment cannot be changed. A service domain fragment can only be changed through a deployment change. There is no automatic redirect from the old service domain to the new one. The service domain fragment remains reserved throughout the entire service lifecycle. Only final deletion releases it for reuse. ## HTTP and HTTPS When deploying a public service, you must select how users should access the service. The available options are **HTTP** and **HTTPS**. ### HTTPS Every service can use the built-in **SSL** or TLS feature. A deployment with this feature enabled automatically receives a Let's Encrypt certificate and upgrades HTTP traffic to HTTPS. The benefit is that users of the service get an additional layer of connection security, and browsers show users that the connection is secure. The default deployment configuration is **HTTPS**. We recommend this setting for most users. Reachability: ```text app.example.hostly.ninja -> https://app.example.hostly.ninja http://app.example.hostly.ninja -> https://app.example.hostly.ninja https://app.example.hostly.ninja -> https://app.example.hostly.ninja ``` The public port for HTTPS traffic is 443. ### HTTP The connection for users of the service is not additionally secured, and browsers show users that the connection is not secure. We recommend this setting only for users who understand the risks. Reachability: ```text app.example.hostly.ninja -> http://app.example.hostly.ninja http://app.example.hostly.ninja -> http://app.example.hostly.ninja https://app.example.hostly.ninja -> error 404, page does not exist ``` The public port for HTTP traffic is 80. ## Related concepts * [Account and Workspace](./account-and-workspace.md) * [What is a Service?](./service.md) * [Service Status and Lifecycle](./service-status-and-lifecycle.md)