Subdomains for Law Firms: Building Client Portals, AI Tools, and Internal Systems

Why subdomains matter for modern law firms

A subdomain is a “section” of your firm’s main domain that lives at the front of your web address — for example, portal.yourfirm.com or ai.yourfirm.com. It still clearly belongs to your firm because the root name stays the same (the yourfirm.com part). That’s different from spinning up a separate domain (like yourfirmportal.com), which can feel disconnected, harder to brand consistently, and easier for clients to mistake for a phishing site.

For law firms, this isn’t just “web nerd” architecture. It’s a practical way to increase client trust — clients see a familiar domain on login pages, document-sharing tools, and intake forms. It also improves clarity: your public marketing site can live on www, while specialized functions live on clearly labeled subdomains (portal, payments, knowledge base, etc.). That separation makes it easier to expand without turning your main site into a maze.

Subdomains also support scalable tool integration. You can add new client-facing services (like secure portals or AI-powered workflows) without redesigning your whole website — and you can move or replace one tool later without disrupting everything else.

This guide is written for lawyers and operations teams: a non-DevOps path using familiar dashboards (Cloudflare + DigitalOcean), with security and privacy considerations woven in. If you’re also evaluating broader security frameworks, see our ISO 27001 guide.

Decide what each subdomain is for before touching DNS

Before you create records in Cloudflare, write down what you want each subdomain to do. A subdomain is easiest to secure (and explain to clients) when it maps to a single purpose, a single audience, and a clear data boundary.

• Client portal: portal.yourfirm.com or clients.yourfirm.com for logins, document exchange, invoices, and status updates. Treat this as “confidential by default.”
• AI tools: ai.yourfirm.com for research assistants, intake triage, or drafting workflows. Keep it separate so prompts, logs, and model/vendor settings don’t mingle with your marketing site or portal data.
• Knowledge base: kb.yourfirm.com or help.yourfirm.com for FAQs and guides. Often public, but still operationally distinct from www.
• Internal tools: ops.yourfirm.com or intranet.yourfirm.com for admin dashboards, automation, and reporting — ideally gated behind SSO/VPN and not indexed.

The rationale is simple: data separation and access control. When tools live on different subdomains, you can apply tighter rules per surface area — different authentication, different logging/retention, different WAF/rate limits, and different vendor connections. It also reduces “blast radius”: if one app is misconfigured, it doesn’t automatically expose everything else.

If you’re working with third-party processors (portal vendors, AI providers, analytics), plan where those services sit and what data flows through them so you can align contracts and security expectations (for example, via a Data Processing Agreement (DPA)).

Prerequisites and setup overview

Before you change DNS, gather a few basics so you can move deliberately (and avoid breaking email, your main website, or client-facing tools).

• A domain you control (registrar login + ability to update nameservers if needed).
• A Cloudflare account with the domain added (you’ll manage DNS, proxying/WAF options, and edge TLS settings).
• A DigitalOcean account (you’ll create an Ubuntu Droplet to host the subdomain app or reverse proxy).
• Access to basic dashboards: Cloudflare DNS, DigitalOcean Droplets/Networking, and (optionally) a password manager for API tokens and SSH keys.

At a high level, the workflow looks like this:

• Plan: confirm what the subdomain is for, who should access it, and what data it will handle.
• DNS: create the subdomain record (typically an A record to the Droplet IP). Decide whether it should be proxied (client-facing) or DNS-only (internal/admin tools).
• Server: provision the Droplet, harden access, and configure Nginx to route traffic for that hostname.
• TLS: enable HTTPS end-to-end (either Let’s Encrypt on the server or Cloudflare Origin Certs + “Full (Strict)” mode).
• Ongoing checks: patching cadence, backups, access logs, certificate renewal, and periodic permission reviews.

Throughout the guide, we’ll flag the legal/privacy implications that matter for firms — especially where a subdomain becomes a client portal or AI tool (confidentiality, vendor roles, and retention). If you need a starting point for documenting responsibilities with vendors, see our Data Processing Agreement (DPA) template.

Step-by-step DNS and Droplet provisioning

• Step 1 (Cloudflare): pick proxy mode for the subdomain. In Cloudflare DNS, create the hostname you want (for example, portal.yourfirm.com). For most client-facing apps, set the record to Proxied (orange cloud) so traffic is routed through Cloudflare for protection and performance. Cloudflare notes that proxied records return Cloudflare anycast IPs (not your server IP), while DNS-only records return your origin IP directly.
• Step 2 (DigitalOcean): create a Droplet. Create a new Droplet using Ubuntu LTS (for example, 22.04 or 24.04), choose a region close to your users, and add an SSH key (preferred) rather than password login. Copy the Droplet’s public IPv4 address.
• Step 3 (DNS): point the subdomain to the Droplet and verify. Add an A record for the subdomain pointing to the Droplet IPv4. After a few minutes, verify propagation from your computer:Note: if the record is proxied, the lookup will show Cloudflare IPs rather than your Droplet’s IP (that’s expected).
  • dig +short portal.yourfirm.com
  • nslookup portal.yourfirm.com
• Step 4 (Nginx): install a minimal server block for the hostname. On the Droplet:Create /etc/nginx/sites-available/portal.yourfirm.com:server {
  listen 80;
  server_name portal.yourfirm.com;
  
  root /var/www/portal;
  index index.html;
  
  location / {
  try_files $uri $uri/ =404;
  }
  }
  Enable and reload:sudo mkdir -p /var/www/portal
  echo "OK" | sudo tee /var/www/portal/index.html
  sudo ln -s /etc/nginx/sites-available/portal.yourfirm.com /etc/nginx/sites-enabled/
  sudo nginx -t && sudo systemctl reload nginx
  
  • sudo apt update && sudo apt install -y nginx

Next, you’ll add TLS (HTTPS) and tighten security for anything client-facing.

SSL, security, and compliance for client subdomains

For anything client-facing (portals, intake, payments), aim for end-to-end HTTPS: browser " Cloudflare " your Droplet.

Certificate option A: Let's Encrypt on the Droplet (publicly trusted; works even if Cloudflare is paused). If Nginx is already serving the subdomain on port 80/443:

• sudo apt update && sudo apt install -y certbot python3-certbot-nginx
• sudo certbot --nginx -d portal.yourfirm.com (choose redirect when prompted)

Certificate option B: Cloudflare Origin CA (encrypts Cloudflare's connection to your origin; pair with Full (strict)). In Cloudflare: SSL/TLS " Origin Server " Create Certificate, then install on the Droplet and reference it in your Nginx server block:

• ssl_certificate /etc/ssl/certs/cf_origin.pem;
• ssl_certificate_key /etc/ssl/private/cf_origin.key;

Then set SSL/TLS encryption mode to Full (strict) for that hostname/zone.

Baseline hardening for client portals:

• Force HTTPS (301 redirect + HSTS once stable).
• Access control: MFA/SSO for admins; least-privilege accounts; separate portal admin from marketing CMS accounts.
• Logging & monitoring: retain access/auth logs; alert on repeated failures and unusual geographies.
• Backups: encrypted backups, tested restores, and defined retention.
• Data residency: choose a Droplet region aligned with client expectations and any contractual obligations.

Risk note: a portal subdomain often handles confidential client documents and messages. Treat it like a high-risk system: minimize third-party scripts, restrict who can deploy changes, and document vendor/security responsibilities (for example, with a Data Processing Agreement).