Digital Presence & Online Policies

How to Set Up a Subdomain for Your Law Firm Using Cloudflare and DigitalOcean

Promise Legal Staff

05 Feb 2026 • 6 min read

If you’re a solo or small-firm lawyer (or the in-house counsel who “ended up owning” the company website), a subdomain can be a clean way to separate a client portal, intake workflow, or knowledge base from your main site without rebuilding everything. But DNS and TLS are unforgiving: one wrong record can take your site down, break forms, or quietly send traffic to the wrong server.

Misconfiguration can also create law-firm-specific risk — like disrupting MX records and misrouting email, exposing confidential client data via an unsecured endpoint, or publishing marketing content that doesn’t match your jurisdiction’s advertising requirements.

This section-by-section guide uses Cloudflare for DNS and a DigitalOcean Droplet for hosting, with the goal of a working HTTPS subdomain and a simple punchlist you can hand to IT (or follow yourself). For a shorter overview, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.

Decide What Your Law Firm Subdomain Is For and Why It Matters

Before touching DNS, decide the purpose of the subdomain — because it determines security, visibility, and what “done” looks like.

Client portal (e.g., clients.yourfirm.com): highly sensitive; must be private-by-default, HTTPS-only, least-privilege access, and careful vendor configuration to protect client confidentiality.
Knowledge base / blog (e.g., resources.yourfirm.com): mostly public; focus on SEO, uptime, and bar advertising compliance (clear disclaimers, no inadvertent attorney-client relationship language).
Internal tools (e.g., ops.yourfirm.com): private; restrict by IP/VPN/SSO where possible, and avoid indexing.
AI intake (e.g., intake.yourfirm.com): sensitive; confirm where data is stored/processed and ensure users understand what is (and isn’t) being submitted.

Mini-example: if “intake” is treated like a public marketing page, you may skip authentication/logging and accidentally expose submissions — or point DNS at the wrong host and misroute traffic. For related setup context, see our Cloudflare + DigitalOcean subdomain walkthrough.

Prerequisites: Accounts, Access, and Basic Concepts

Cloudflare access: your firm’s domain is added to Cloudflare, and you can edit DNS records.
Registrar access: you can view/change nameservers and confirm domain ownership details (critical if anything breaks).
DigitalOcean account: billing enabled, plus permission to create/manage Droplets and firewalls.
A Droplet (or a plan): an Ubuntu LTS server to host the subdomain, or an existing server you’re confident you can safely reuse.
SSH basics: you can connect via an SSH key (preferred) and run basic admin commands.
Web server choice: NGINX recommended (Apache works too), and you know which one you’ll configure.

Quick glossary: DNS tells the internet where your subdomain lives; an A record points a name to an IPv4 address; a CNAME points a name to another name; a Droplet is DigitalOcean’s VM; TLS enables HTTPS encryption.

Sanity check: write down the current DNS records (especially MX/email), confirm who controls Cloudflare and the registrar, and decide the exact hostname (e.g., clients.yourfirm.com) before making changes. If you want a higher-level walkthrough first, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.

Verify Your Domain and DNS Are Managed in Cloudflare

First confirm Cloudflare is your authoritative DNS provider. In Cloudflare, open your site and check the DNS area — if records are present and editable, that’s a good sign. Then verify at your registrar that the domain’s nameservers match the two Cloudflare nameservers assigned to your zone (if they don’t, Cloudflare won’t be “in charge,” and your changes won’t take effect).

Registrar: confirm the active nameservers are Cloudflare’s.
Cloudflare: go to DNS → Records and review A/CNAME/MX/TXT.
Backup: export a zone file via DNS → Records → Import and Export → Export so you can roll back quickly.

Propagation note: nameserver changes can take hours to fully propagate. Mini-scenario: a firm switches nameservers but forgets to recreate MX records in Cloudflare — email stops delivering until the correct MX/TXT records are restored.

Create or Select a DigitalOcean Droplet for Your Subdomain

You can host a subdomain on an existing Droplet, but creating a new Droplet is usually safer if the subdomain will handle sensitive data (client portal/intake) or you want clean separation for troubleshooting and access control. Reuse an existing Droplet when it’s already hardened, monitored, and you’re comfortable adding another site to that server.

Region: pick the closest compliant location for your firm’s needs (latency + any data-location expectations).
Image: choose Ubuntu LTS.
Access: add SSH keys (avoid password login if possible).
Firewall: allow inbound 22 (restrict to your IP if you can), plus 80/443 for web traffic.
Health check: SSH in and run updates (e.g., sudo apt update && sudo apt -y upgrade).

Optional stability: attach a reserved/static IP so a rebuild doesn’t change your DNS target. Mini-scenario: you migrate to a new Droplet for security; if you update the Cloudflare A record to the new IP (or move the reserved IP), cutover is minutes instead of an all-day “why is it still going to the old server?” mystery.

Point Your New Subdomain to the Droplet in Cloudflare DNS

In Cloudflare, go to DNS → Records → Add record. For a Droplet, you’ll usually create an A record:

Type: A
Name: clients (creates clients.yourfirm.com)
IPv4 address: 203.0.113.10 (your Droplet’s public IP)
TTL: Auto is fine while testing; lower TTL can speed changes during cutover.
Proxy status: start with DNS only (grey cloud) for troubleshooting; enable Proxied (orange cloud) later if you want Cloudflare WAF/caching and you’ve confirmed HTTPS end-to-end.

Alternative: use a CNAME when pointing the subdomain to another hostname (e.g., a managed service), not directly to an IP.

Test: run dig clients.yourfirm.com (should return the expected IP) and ping or curl -I http://clients.yourfirm.com. Common pitfalls: typo in the record name, old DNS cached (wait/flush), or proxy enabled before the origin server is ready.

Configure Your Web Server for the Law Firm Subdomain

NGINX (recommended): install and create a server block for the subdomain. Example file: /etc/nginx/sites-available/clients.yourfirm.com:

server_name: clients.yourfirm.com
root: /var/www/clients.yourfirm.com
index: index.html index.htm
location /: try_files $uri $uri/ =404;

Enable and reload: sudo ln -s /etc/nginx/sites-available/clients.yourfirm.com /etc/nginx/sites-enabled/, then sudo nginx -t and sudo systemctl reload nginx.

Apache alternative: create a <VirtualHost *:80> with ServerName clients.yourfirm.com and DocumentRoot /var/www/clients.yourfirm.com, then enable the site and reload Apache.

Directory/permissions: create the web root and a test index.html; ensure the web server user can read it. Mini-scenario: if server_name/ServerName is wrong (or missing), NGINX/Apache serves the “default” site — fix by matching the exact hostname and reloading.

Add HTTPS with Let’s Encrypt and Cloudflare for Confidential Client Traffic

For any client-facing subdomain, treat HTTPS as non-optional. Start by confirming your DigitalOcean firewall (and any server firewall) allows inbound 80 and 443.

Install Certbot: on Ubuntu, install certbot plus the plugin for your web server (NGINX or Apache).
Issue a cert: NGINX example: sudo certbot --nginx -d clients.yourfirm.com. Apache example: sudo certbot --apache -d clients.yourfirm.com. Certbot can update your vhost/server block automatically.
Renewal: verify auto-renew with sudo certbot renew --dry-run.

Cloudflare TLS mode: avoid Flexible for confidential traffic (it can leave the Cloudflare→origin leg unencrypted). Use Full (strict) when your origin has a valid certificate (Let’s Encrypt qualifies), so encryption is end-to-end and misissued/expired certs fail closed.

Validate: load https://clients.yourfirm.com, confirm the certificate matches the hostname, and enable an HTTP→HTTPS redirect. Reminder: if this subdomain collects intake details or documents, keep it HTTPS-only and test before enabling Cloudflare proxy/WAF.

Test, Troubleshoot, and Avoid Common Pitfalls

DNS resolves correctly: dig clients.yourfirm.com should return the intended IP (or Cloudflare proxy IPs if proxied).
HTTP/HTTPS work: curl -I http://clients.yourfirm.com and curl -I https://clients.yourfirm.com should return expected status codes (often 200/301).
Certificate matches: in a browser, confirm the cert is valid for the exact hostname and not the server’s default site.
Content loads: verify login/forms, uploads, and any embedded assets (no mixed-content warnings).

Common fixes: propagation delays (wait/flush DNS; lower TTL next time), certificate mismatch (wrong server_name/ServerName or wrong cert installed), redirect loops (Cloudflare “Flexible” + origin redirect), and email disruption (avoid touching MX/TXT unless you intend to).

Migration regression control: document the current DNS/vhost settings, stage the new Droplet, test via a temporary hostname, then do a short cutover window (update A record/reserved IP), and keep the old server available for quick rollback.

Law-Firm-Specific Best Practices: Security, Jurisdiction, and Website Policies

Security basics: patch routinely, use SSH keys (disable password auth if possible), restrict inbound ports to what you need (22, 80, 443), and enable backups + monitoring/alerts.
Jurisdiction & data location: choose a Droplet region intentionally. If the subdomain handles client documents/intake, confirm where data is stored, who can access it, and whether your matter or client contract expects a particular geography.
Policies: update (or add) a privacy notice and terms for the subdomain’s actual functionality (forms, portals, analytics/cookies). Ensure marketing pages on subdomains still meet attorney advertising and disclaimer requirements in the jurisdictions where you practice.

Involve your firm’s security/compliance point person before launching anything that collects sensitive data or uses third-party tools (chatbots, intake AI, analytics). Related: How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.