Custom domains

An exposed HTTP app has a Suji address such as https://<subdomain>.suji.fr. Add a custom domain from the app’s Domains section to use an address you own, such as app.example.com. Each install supports a primary custom domain and an optional matching apex/www alias. The access mode is shared by custom domains on the same VM, so review the impact on its other apps before changing modes.

​

Choose an access mode

Cloudflare mode routes visitors through your Cloudflare account. Its security features depend on your plan and configuration; selecting this mode does not enable every WAF feature or make the VM’s public IP secret. Direct mode exposes the VM’s web endpoint without Cloudflare’s edge in front of it. Configure your app’s own authentication and access controls in either mode.

​

Add and verify the domain

1. Open the exposed app’s Domains section, enter your domain and select the available mode.
2. Copy the exact ownership TXT record shown by the dashboard into your DNS provider. For app.example.com, the record name is _suji-verify.app.example.com.
3. Add the A record shown by the dashboard, pointing the domain to the VM’s IPv4 address.
4. In Cloudflare mode, enable the orange-cloud proxy and set the zone’s SSL/TLS mode to Full. The default origin setup is not intended for Flexible or Full (strict). In Direct mode, leave the DNS record unproxied.
5. Click Verify, then follow the domain status until it becomes active. Check the public URL in your browser.

DNS propagation, origin configuration and certificate issuance can take time. If activation fails, use the reason shown in the dashboard to check the TXT record, A record, proxy mode, firewall and TLS configuration. Keep the ownership TXT record in place after setup.

​

Primary URL and integrations

When activation and cutover complete, Suji configures a 301 redirect from the app’s Suji hostname to the custom domain, preserving the path and query string. While setup is pending, continue using the Suji hostname. Suji updates supported template variables that represent the app’s public address. Separately stored settings and third-party registrations can still need changes. Update OAuth callbacks, webhook destinations and app settings as required, then test them. A 301 redirect does not guarantee that a webhook client follows it or preserves the request method. Check both addresses after cutover; DNS, certificate or redirect changes can fail or take time to apply.

​

Apex and www

For an apex domain such as example.com, enable the matching www.example.com alias if needed, or use the corresponding option when the primary is www. Configure DNS for both names as the dashboard instructs. The alias redirects visitors to the primary address. Use the displayed A-record instructions for the apex. Do not substitute a CNAME or flattening configuration unless you understand how it affects the required proxy mode and destination.

​

Domain failures and removal

If Suji detects that ownership verification has been lost, it attempts to remove the custom-domain redirect and restore service on the original Suji hostname. This is not a failover guarantee for every outage: an active domain’s certificate or connectivity failure does not necessarily trigger that recovery path. Check the domain’s status and both addresses when troubleshooting. If needed, remove the custom domain from Domains, wait for the change to apply and confirm that the original Suji URL serves the app. Then update integrations and remove unused DNS records.

​

Traffic charges

Incoming traffic is not billed by Suji’s traffic meter. Outgoing traffic, including responses to direct requests, counts toward the VM’s monthly allowance. Direct-mode exposure can therefore generate billed outgoing traffic if the allowance is exceeded. See Network for units, rates and rounding.

​

Next