Building

Domains & uptime

Custom domains, automatic SSL, and letting idle apps sleep to save money.

The URL you get by default

Every app is given a subdomain when it is created. You do not configure anything for it — it exists from the first deploy, and it is what the dashboard links to.

https://my-app-a1b2c3.clikdeploy.com

The suffix is a short hash, so two people can both have an app called my-app. The name stays the same across redeploys and retries.

Traffic to that subdomain arrives at a reverse proxy — a server that receives the request and forwards it to the right container — which routes it to your app on the right server and port. HTTPS is included, and you do not set up any DNS for it.

Using your own domain

You can point a domain you already own at an app. It takes two steps: tell the platform the domain, then add one DNS record at your registrar.

1. Tell the platform. From the CLI:

clikdeploy app domain my-app app.example.com

In the dashboard, open the app and type the domain into the domain field. If the domain is already registered to you, choose Connect it.

2. Add the DNS record. At whichever registrar or DNS provider holds the domain, create one record pointing at your server's IP address. The dashboard shows the exact IP after you connect the domain, and clikdeploy server list prints the IP of every server you have.

Field	Value
`Type`	A
`Name`	The host you are pointing — `@` for the bare domain, `app` for `app.example.com`.
`Value`	Your server's IP address.

That is the whole change at the registrar. Nothing else needs moving, and your nameservers stay where they are.

If you have connected Cloudflare under Settings → Integrations and the domain is a zone in that Cloudflare account, the record is created for you. Otherwise you add it by hand, and the app works as soon as it resolves.

Removing a custom domain is reversible — the app stays reachable on the subdomain it was given.

SSL

HTTPS certificates are issued and renewed automatically, on every plan, for the platform subdomain and for custom domains alike. For a custom domain the certificate is issued once DNS resolves to your server — usually a few minutes after you add the record.

There is a per-app SSL toggle if you need to turn it off, which you rarely do. It is a toggle, not a switch with an argument: running it twice returns you to where you started.

clikdeploy app ssl my-app

Sleeping idle apps

Scale-to-zero stops an app's container when nothing has used it for a while, and starts it again on the next request. A stopped container uses no memory and no CPU, which is the point — you pay for the server, so an idle app that is stopped leaves room for one that is not.

The cost is a cold start: the first request after a sleep waits for the container to boot. How long depends entirely on your app — a small service is a second or two, something JVM-shaped is longer. Nothing is dropped; the request waits.

The four modes

Mode	Behaviour
`always`	Never sleeps. The default. No cold starts, and you pay for it idle.
`on-demand`	Sleeps whenever idle, wakes on the next request. The most savings.
`scheduled`	Kept awake during hours of the week you pick; sleeps outside them.
`adaptive`	Kept awake during hours it has learned are busy, from real traffic. Needs about a week of history before it is trusted.

Wake-on-traffic and the idle timeout sit underneath all four, so a schedule or a learned guess being wrong costs a cold start and nothing more.

Turning it on and off

# what is this app set to?
clikdeploy app uptime my-app

# sleep when idle
clikdeploy app uptime my-app on-demand

# sleep after 30 minutes idle instead of the default 15
clikdeploy app uptime my-app on-demand --idle-timeout 30

# back to always on
clikdeploy app uptime my-app always

The idle timeout is 15 minutes by default and can be set between 2 minutes and 24 hours. A background sweep checks about once a minute, so sleeping happens shortly after the timeout, not to the second.

Apps that cannot be put to sleep

The platform only sleeps an app it is certain it can wake. An app it could stop but not restart would be down with no way back, so those apps are left running even if you asked for on-demand.

Apps on a server connected with the ClikDeploy agent — the agent is the small process that runs on your server and keeps a connection open to the platform. It can always start a container, so these apps can always be woken.
Apps on a cloud server, reached on their platform subdomain — their traffic passes through the platform's proxy, which starts the container and then forwards the request. These can be woken.
Apps on a cloud server reached only on a custom domain — that traffic goes straight to your server and never touches the platform, so there is nothing to notice the request and start the container. These are not slept unless the platform operator has enabled edge wake for custom domains.
Apps that receive events from another app and have never had an uptime mode set explicitly. Their traffic may arrive over the event bus rather than as web requests, and sleeping one would silently drop deliveries.
Apps another running app depends on — a shared database, for example. These are skipped while the app that links to them is up.

A custom domain can stop a cloud app from sleeping

On a cloud server, wake-on-traffic works because requests reach the platform proxy first. Point that app at a custom domain and requests go directly to your server, so the platform never sees the first one. It responds by refusing to sleep the app at all — safe, but not the saving you set up. Apps on agent-connected servers are not affected: they can be woken on any domain.

Related: deploying apps for environment variables, backing services and what to do when a deploy fails.

ClikDeploy