Addresses and domains

The address every application gets, using your own name instead, and what breaks when DNS is wrong.

The address you get for free

Every published application gets an address under the platform's own domain as soon as it runs. It is encrypted, the certificate is obtained and renewed for you, and it keeps working forever.

That last point matters more than it sounds: your own domain is served alongside the platform address, never instead of it. If your domain expires, if a record is deleted, or if you hand the domain to someone else, the platform address still reaches your application. It is the address support will ask you for when your own name is the thing that is broken.

Using your own domain

Attach the name to the application, then point the name at the platform. The console shows exactly which record to create.

Two ways to hold the name:

A domain you already own elsewhere. Tell ISOGrid about it and create the record your registrar's control panel asks for. You keep managing the name; the platform only routes it.

A domain bought through ISOGrid. The platform registers it on your behalf and manages its records, so pointing it at an application is one action and there is no second control panel to learn.

The certificate

Once the name resolves to the platform, a certificate is obtained automatically and renewed before it expires. Nothing to install and no renewal to remember.

The order matters: the certificate cannot be issued until the name actually resolves to the platform. A certificate authority proves you control a name by reaching it. If you attach a domain and it shows as pending for a long time, the record is almost certainly not in place yet, or not in place everywhere yet.

What you cannot do

You cannot claim a name under the platform's own domain. Those are handed out, not requested. Letting a tenant claim one would let them take over routing for an address the platform has promised to somebody else.

You cannot point two applications at the same hostname. One name routes to one application. The second attempt is refused rather than silently winning, because "silently winning" means someone else's site starts serving on your domain.

Restricting who can reach it

An application can be limited to a list of addresses that may connect, or a list that may not.

An allow list is closed. Naming who may connect denies everyone else, which is the only reading that makes an allow list mean anything.

A deny list is not. Anything it does not name still gets through.

Setting both is contradictory, and the allow list wins. If you have named who may connect, naming someone who may not adds nothing.

Addresses are normalised when you save them, so what you see afterwards may be written differently from what you typed. It means the same range.

Rate limiting

You can cap how many requests a single client may make per minute. Over-limit requests are refused with a clear status rather than a vague server error, so a client library can tell "you are going too fast" from "the server is broken".

The limit has a burst allowance, and it needs one: a browser opening a single page makes a dozen requests at once, so a limit with no burst rejects the very page that configured it.

Each application has its own budget. Your limit is not shared with anyone else's application.

Edge cases worth knowing before you meet them

The domain works for you and not for your colleague. DNS changes do not reach everyone at once. Until every resolver has caught up, some people reach the new place and some the old. Nothing is wrong; it needs time.

The certificate will not issue and the record looks correct. Check whether anything sits in front of your domain — a proxy or protection service that answers on your name before the platform does will answer the certificate authority's check too, and the check will fail. Either let the challenge through or move the name.

The site loads over an insecure connection but not a secure one. The name resolves but the certificate is not there yet. Wait for it rather than working around it.

You changed a record and the old one came back. Some registrars keep a default record that is re-applied when you edit a different one. Check the full list of records rather than the one you edited.

The domain expired. Everything stops resolving, including the certificate renewal, and the platform cannot fix it — only the registrar can. Your platform address is unaffected, which is why it still exists.

You moved the domain to another provider. Records do not travel with it. Recreate them at the new provider before the change takes effect, or there is an outage between the two.