A domain gives users a stable address. HTTPS protects a connection and helps the client verify the endpoint it reached. Neither decides who should be allowed to run your agent. A useful deployment plan handles naming, transport protection, and application access as separate concerns.

This is an unexecuted reference workflow for a public hostname with Caddy as the entry point. We have not changed DNS, obtained a certificate, or tested an agent deployment for this guide. A private service, wildcard certificate, external load balancer, or CDN can require a different validation and trust design.

Establish ownership and the request path

Confirm who controls the domain registration and authoritative DNS. Keep account recovery available to more than one appropriately authorized operator if the service depends on it. Record the intended hostname, server address, responsible person, and any existing records before changing anything.

Draw the complete path: client, optional CDN or proxy, Caddy, and application. Mark which connection is public and which service terminates TLS. Identify whether the application also needs encryption on its upstream connection. Do not assume that securing the browser-to-proxy connection automatically secures a separate network hop.

For an initial deployment, prefer a dedicated application hostname rather than changing an unrelated main website. Confirm that callbacks and allowed origins in connected services use the same intended address. A successful homepage does not prove an OAuth callback or webhook will reach the correct application.

Make DNS and certificate assumptions explicit

For its usual public-domain automation, Caddy documents the need for correct A/AAAA records, reachable ports 80 and 443, access to those ports, a configured domain, and writable persistent data storage. Review the current automatic HTTPS requirements before selecting this approach. DNS-based validation has different requirements and may introduce a DNS-provider credential.

Only publish an IPv6 record when the intended service and firewall path work over IPv6. A leftover address can send some clients to a different or unreachable server. Check the answer from outside your local network and compare it with the deployment record.

DNS changes are not an instantaneous traffic switch. TTL influences how long records remain cached; Cloudflare’s TTL reference explains why updates take time to reach users. Allow for existing caches when moving a service. Lowering a TTL does not retroactively remove an earlier cached answer.

Connect Caddy to a private upstream

Choose where Caddy runs before selecting the upstream address. Inside a container, its loopback address refers to that container, not automatically to the host or another service. In a shared container network, use the application service’s reachable internal address. With a host-based proxy, configure the application’s host binding accordingly.

Keep the raw application listener away from public clients when access controls depend on the proxy. Docker’s publishing reference describes default exposure and restricted bindings. Check both the proxy route and direct access to the origin; the latter should not offer a way around your intended authentication boundary.

Give the proxy persistent storage for its operational data and an explicit update process. Avoid repeatedly deleting its state as a troubleshooting habit. Keep logs useful, but do not include bearer tokens or sensitive query parameters in a diagnostic screenshot.

Add authentication and authorization

Decide who may sign in and what each role may do. Test an anonymous visitor, an ordinary user, and an administrator separately. Protect job creation, file downloads, stored conversations, and tool-action endpoints, not only the visible dashboard.

A certificate does not grant user authorization. Likewise, a login screen does not prove backend APIs enforce permissions. Verify that a user cannot retrieve another user’s task by changing an identifier. For an agent with external actions, approvals should bind to the destination and content of the action, even after the user has signed in.

If Cloudflare proxies the service, review the origin connection as well as the edge certificate. Full (strict) validates the origin certificate against its documented requirements. Do not weaken origin validation merely to make an error disappear; investigate the hostname, certificate, and connection path.

Verify launch and future renewal

Use the real public hostname from a separate network. Confirm the correct application loads, HTTPS is valid for that hostname, redirects behave as intended, and authenticated requests succeed. Check that unauthenticated API calls fail safely and that the internal listener remains inaccessible directly.

Exercise the application features that need persistent connections or long responses. Confirm that uploads, streamed results, and callback URLs behave correctly through the proxy. Record failures without assuming every timeout is a model problem.

Finally, assign ownership for certificate-expiry alerts, DNS changes, domain renewal, and proxy updates. Caddy automates certificate management under its documented conditions, but an expired domain, changed firewall, or lost state can still break a service. Keep a known-good configuration and a recovery route that does not depend on the broken public hostname.