Concepts in Tech for Lawyers

How to Set Up Law Firm Subdomains with Cloudflare and DigitalOcean

Promise Legal Staff

10 Feb 2026 • 5 min read

Introduction and goals for law-firm subdomains

Law-firm subdomains let you separate functions (client portals, document delivery, intake, knowledge base) without rebuilding your main site. In this guide, we’ll focus on the practical, repeatable steps to publish subdomains like portal.examplelawfirm.com and docs.examplelawfirm.com using Cloudflare DNS and a DigitalOcean Droplet (or similar VPS).

This guide is for lawyers, administrators, and IT vendors who want a setup that is: (1) predictable to deploy, (2) easy to audit later, and (3) compatible with common security expectations for client-facing systems.

By the end, you should be able to:

Create DNS records for one or more subdomains and verify they resolve correctly.
Decide when to use Cloudflare’s proxy (“orange cloud”) versus DNS-only, based on your app and troubleshooting needs.
Route traffic to a server and serve each subdomain with the correct hostname and HTTPS.

High-level flow: a browser requests portal.examplelawfirm.com → Cloudflare answers DNS (and may proxy the request) → the request reaches your Droplet (often through Nginx) → TLS is terminated either at Cloudflare’s edge or on the Droplet. Cloudflare’s SSL/TLS “encryption mode” determines whether Cloudflare connects to your origin over HTTP or HTTPS and whether it validates your origin certificate (for example, Full (strict) validates the origin cert).

If you want a shorter walkthrough of the same concept, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.

Prerequisites and planning: domain, Cloudflare, and hosting readiness

Before touching DNS, confirm you have the pieces (and the decision-makers) lined up. Subdomain work goes quickly when ownership and access are clear.

Domain control: You need admin access at the registrar (where the domain is purchased) and/or whoever currently hosts DNS. If you are moving DNS to Cloudflare, plan a short maintenance window and disable DNSSEC at the registrar first to avoid connectivity errors during nameserver changes.
Cloudflare account + zone: Add/onboard the apex domain (examplelawfirm.com) in Cloudflare and verify the imported DNS records are complete — especially existing web and email records — before switching nameservers.
Hosting target: A public server to receive web traffic, such as a DigitalOcean Droplet, with a known IPv4 address (and optional IPv6). Decide whether each subdomain will be a separate app, a folder on the same server, or a separate server.
SSH access: Key-based SSH access for at least two people (or a documented break-glass procedure) so you can update web server configs and certificates without delays.
Something to serve: A simple “it works” page or a minimal app that returns 200 OK for each hostname. This makes DNS and TLS troubleshooting much easier.

Naming convention: pick clear, purpose-based names (e.g., portal, docs, intake, status) and avoid personal names or ambiguous abbreviations. Reserve a prefix like dev- or staging- if you’ll test changes safely.

Governance decisions: maintain an inventory (subdomain → owner → vendor/app → data sensitivity → decommission date). Also decide which records may be proxied through Cloudflare versus left DNS-only; per Cloudflare, proxied A/AAAA/CNAME records return Cloudflare anycast IPs, while DNS-only records reveal the origin IP.

Step-by-step DNS and Cloudflare setup (A vs CNAME, Proxy vs DNS-only)

In Cloudflare, go to DNS → Records → Add record. For each subdomain, you’ll choose a record type, fill in the core fields (Name, Content/Target, TTL), and set Proxy status (orange-cloud “Proxied” vs gray-cloud “DNS only”). Cloudflare only proxies A, AAAA, and CNAME records.

A record (most common for a Droplet): Type = A, Name = portal, Content = <your Droplet IPv4>, TTL = Auto, Proxy status = Proxied (recommended for web traffic) or DNS only (useful for initial debugging).
CNAME record (alias): Type = CNAME, Name = docs, Target/Content = portal.examplelawfirm.com (or a vendor hostname), TTL = Auto, then choose proxy status. Keep verification-only CNAMEs (some SaaS, ACME challenges, etc.) DNS only.

Proxy vs DNS-only: When proxied, DNS answers return a Cloudflare anycast IP instead of your origin IP, and Cloudflare can cache/protect traffic. When DNS-only, queries return the actual origin IP and you lose most Cloudflare edge features.

Test it (from your laptop):

dig +short portal.examplelawfirm.com (expect Cloudflare IPs if proxied; expect your Droplet IP if DNS-only)
dig +trace portal.examplelawfirm.com (useful when you suspect delegation/nameserver issues)
curl -I https://portal.examplelawfirm.com (verifies HTTP status and certificate presentation)

Propagation reality: even with low TTLs, your OS/browser/ISP resolver may cache longer. If you change records and still see old answers, try a different resolver (for example, dig @1.1.1.1 …) or flush local DNS.

Common pitfalls: (1) pointing the subdomain at the wrong IP, (2) proxying a hostname that must remain DNS-only (certain vendor/validation records), and (3) leaving a mix of proxied and DNS-only A/AAAA records on the same name — Cloudflare treats the name as proxied if any A/AAAA on that name is proxied.

Server configuration and TLS: Nginx/Apache configuration and HTTPS enablement

Once DNS resolves to your Droplet, the server must (1) listen on ports 80 and 443, (2) match requests by hostname, and (3) present a valid certificate for each subdomain. Most setups use Nginx as the TLS terminator and reverse proxy to an app on localhost.

Minimal Nginx example (one subdomain):

server {
listen 80;
server_name portal.examplelawfirm.com;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
server_name portal.examplelawfirm.com;

ssl_certificate /etc/ssl/certs/portal.pem;
ssl_certificate_key /etc/ssl/private/portal.key;

location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

Certificates: Let’s Encrypt vs Cloudflare Origin CA. If the subdomain is not proxied (DNS-only), use a publicly trusted cert such as Let’s Encrypt. If the subdomain is proxied through Cloudflare, you can use a Cloudflare Origin CA certificate to encrypt traffic between Cloudflare and your server. Cloudflare notes Origin CA certs are compatible with Full (strict) mode, but browsers will not trust them if you pause Cloudflare or turn proxying off.

Cloudflare Origin CA workflow: create the cert in Cloudflare (SSL/TLS → Origin Server), install it on the Droplet, then set SSL/TLS encryption mode to Full (strict) in Cloudflare.

Validation commands: nginx -t then systemctl reload nginx; verify externally with curl -I https://portal.examplelawfirm.com and (for origin debugging) openssl s_client -connect <origin-ip>:443 -servername portal.examplelawfirm.com.

Security, governance, and troubleshooting: risk considerations and next actions

For law firms, subdomains aren’t “just DNS.” Each hostname can become a new entry point for client data, credentials, and reputational risk. Treat every new subdomain as a system that needs an owner, a purpose, and an end-of-life plan.

Data handling: document what data the subdomain will process (PII, PHI, payment info, client documents) and where it is stored. If a vendor is involved, capture their security attestations (for example, SOC 2 Type II) and retention/deletion terms.
Access controls: require MFA for admin panels, use least-privilege SSH keys, and remove shared accounts. Limit origin access to Cloudflare IPs when feasible (and keep the list updated).
TLS governance: prefer Full (strict) so Cloudflare validates the origin certificate. Cloudflare’s docs note Origin CA certificates only encrypt traffic between Cloudflare and your origin (browsers won’t trust them if you pause Cloudflare or disable proxying).
Inventory + lifecycle: maintain a register: subdomain → business owner → technical owner → DNS record(s) → origin server/app → certificate method → renewal date → decommission date.

Troubleshooting quick reference:

Resolves to the “wrong” IP: if proxied, Cloudflare returns anycast IPs, not your origin IP. Confirm proxy status in Cloudflare DNS and test with dig +short.
526 / certificate errors: your origin cert is missing/invalid for Full (strict). Confirm SAN coverage for the hostname and verify with openssl s_client -servername.
Too many redirects: usually double HTTPS redirects (Cloudflare “Always Use HTTPS” plus origin redirects). Disable one side and re-test with curl -I.
Works in DNS-only, fails when proxied: check Cloudflare-supported ports and WAF/firewall blocks on the origin.

See Cloudflare’s reference on proxy status and Origin CA behavior.