Serverless DNS and IP address change
We need to change the IP addresses used for incoming traffic to Serverless (Rapids) containers. Your container's danubedata.run hostname will stay the same.
Status: preparation. The DNS cutover has not happened. Keep your current settings while you review the checks below. The change window and final address instructions will be published here before cutover.
Check how your domain connects
Open your container in the console and copy its default danubedata.run hostname. Use the exact hostname shown for that container, without https:// or a path.
Then check the record in your DNS provider's dashboard:
| Your configuration | What to check now |
|---|---|
You use the default danubedata.run hostname directly | Keep using that hostname. DanubeData manages its DNS records. |
| Your custom domain has a CNAME to the container's exact hostname | Keep the existing CNAME target. Check that your CDN or proxy has no separate fixed-IP origin override. |
| Your root domain uses ALIAS, ANAME or a flattened CNAME | Confirm in your provider's dashboard that its target is the container's exact hostname. Public DNS may show only the resolved IP addresses. |
| Your domain has fixed A or AAAA records | Record both values and contact support through the console for migration guidance. Wait for the final address instructions before replacing them. |
| You use a CDN, reverse proxy or load balancer | Check the configured origin and any origin override or backend pool. Public DNS may show the proxy's addresses rather than the origin. |
For example, a custom domain might use:
api.example.com CNAME my-api-acme.danubedata.run
Copy the target from your own container. The hostname above is only an example.
Check fixed IP dependencies
The current serverless addresses being replaced are:
| Record | Current address |
|---|---|
| A (IPv4) | 138.199.134.76 |
| AAAA (IPv6) | 2a01:4f8:c011:462::1 |
Look for these values in DNS records, CDN origin settings, reverse-proxy configurations, destination allowlists and clients that connect to a fixed IP. Check IPv4 and IPv6 separately.
If you find a fixed address, open a support ticket from the console with the affected hostname and the type of configuration. Do not include passwords, API tokens or private keys. We can help confirm the right migration action before you change it.
Optional DNS checks
You can inspect public records with:
dig +noall +answer api.example.com CNAME
dig +noall +answer api.example.com A
dig +noall +answer api.example.com AAAA
Replace api.example.com with your domain. An empty CNAME answer does not by itself mean the configuration is wrong: a proxy or flattened alias can hide the target. Check the provider's dashboard too.
During the change
A CNAME that already points to your container's correct hostname can keep that target. DanubeData will update the platform hostname's address records during the announced window.
DNS answers are cached, so different clients may use different addresses during the transition. Existing long-lived connections do not move just because DNS changes. Applications should support reconnecting and retrying failed requests safely.
Keep domain-verification and certificate-validation records in place. The custom domains guide explains how to identify your container's target and manage its domain settings.
Need help?
Open a support ticket from the DanubeData console and include your affected domain. If it points to another hosting provider or redirects to another hostname, describe that setup so we can check whether it depends on the serverless IP addresses.