Connect a domain

Publish the required DNS records, verify HTTPS, and route requests to services.

Copy page

Connect your own hostname under Service → Networking, publish the DNS records Lepsto returns, and wait for Active. HTTP services receive a generated lepsto.run hostname by default; assigning a hostname and making it serve are separate steps.

Before you start

• Have a deployed HTTP service in the target environment.
• Register the base domain for the target product and have access to its DNS provider. Lepsto lists available base domains.
• For MCP, use a product-scoped token with Deployment admin for adding/removing domains and editing routes, write for verification, and read for inspection.

1. Add the hostname

Open Service → Networking. Choose an available base domain, its root or a subdomain such as api, and the default service. MCP uses deployment_domain_add with environmentId, hostname and defaultServiceId.

A hostname is unique across environments. To use an existing hostname in the same environment for another service, supply a path prefix instead of creating a second domain.

2. Publish every returned record

Copy the exact records from the domain’s record list to your DNS provider. If the platform manages your DNS, it publishes them for you.

Replace <your-host> with your hostname; do not invent targets or copy addresses from another domain. Root-domain addresses are resolved when you add the domain. If that resolution fails, the add is refused; retry after the reported problem clears.

If a CDN or DNS proxy currently fronts the hostname, turn off proxying so DNS resolves to the returned target. Keep it off until the domain reaches Active; a proxied address cannot pass the address comparison.

3. Wait for DNS and HTTPS

Lepsto checks DNS every minute. Use deployment_domain_verify to request a check and deployment_domain_get to inspect progress.

When an _acme-challenge record is supplied, certificate issuance waits until it is visible in public DNS. Once visible, issuance normally takes minutes. If no challenge record is supplied, verification through the serving network takes tens of minutes. Do not omit a supplied challenge record.

Verify it works

Open the hostname over HTTPS and check that the intended service answers. Request an HTTP URL with a path and query: it should redirect permanently to the equivalent HTTPS URL, preserving host, path and query.

For a root domain with the www option enabled, also check the redirect from www. Its separate certificate can take tens of minutes after the root domain starts serving. The option is on by default for root domains and can be changed in the domain row or with deployment_domain_redirect_www.

Route paths to different services

Edit routes on the custom domain under Service → Networking, or call deployment_domain_routes_add.

Replace these service names with yours. Each target must be in the domain’s environment. Paths are unique per domain; missing leading slashes are added and trailing slashes removed. The longest matching prefix wins; equal specificity uses higher priority. The default / route catches the remaining requests. You can change its target, but cannot delete it.

Route changes need no redeploy. Test one URL under each prefix after saving.

Generated domains

A generated hostname looks like api-3f9c2b71.lepsto.run: the service slug and a unique suffix. It routes / to that service and accepts no extra routes. It is removed with the service.

To remove only the generated public hostname and route, use deployment_service_update with publicDomain: false (Deployment write access). Set it to true to recreate the same hostname. This does not remove custom domains attached to the service; inspect those separately if you want to stop public access.

The generated route usually spends 2–5 minutes provisioning, then a few more minutes propagating. Active means an external check received a response from the service; only then is the address shown as a clickable link.

For Route failed, read the status hint, check the service’s deployment, port and health check, then redeploy if routing needs to be reapplied. A sleeping service can still answer route checks by waking first.

Remove a custom domain

deployment_domain_remove removes its routing and certificate and stops serving that hostname. Check which clients depend on the address before removing it.