The engineering and professional services team here at Atlantic.Net responds to customer requests for quotes almost every day. A HIPAA hosting RFQ often arrives as a checklist stating the client’s requirements and expectations. Today, we are focusing on a recent request from a customer who wanted to onboard into our award-winning HIPAA-Compliant Hosting Services.

The RFQ was clear; the customer wanted a Django application on its own VM, a separate database VM, a signed HIPAA Business Associate Agreement (BAA), a managed firewall with intrusion prevention, encrypted backups in more than one location, multi-factor authentication, vulnerability scanning, and VPN access

To our clients, every detail matters. But the checklist is not the architecture.

The real work was turning a sensible HIPAA hosting wishlist into a secure, provisionable environment. The RFQ arrived on a Monday, the quote was signed the following week, and shortly after, Atlantic.Net began provisioning a two-VM Django deployment behind a managed FortiGate firewall in Dallas, with encrypted offsite backups stored in Ashburn, Virginia.

The result was a clean, public-facing application tier, a private database tier, a managed security perimeter, and the compliance controls needed before ePHI entered the stack.

The HIPAA Hosting Wishlist

The customer was building a Django application that would handle electronic Protected Health Information, payment activity, and webhook traffic from external systems. They had already ruled out a single-server deployment. That was the correct decision and a great sign that everyone was working on the same page.

A HIPAA workload that combines a public web application with a database containing ePHI should not start with everything on one VM unless there is a strong reason to do so.

The customer’s RFQ included:

  • An application VM with roughly 6 vCPU, 16GB of RAM, and 200GB of SSD storage
  • A database VM with roughly 4vCPU, 16GB of RAM, scalable storage, and private-network access
  • A signed HIPAA BAA before ePHI was introduced
  • A managed FortiGate firewall or equivalent
  • Private networking between the two VMs
  • VPN connectivity for external integrations
  • Encrypted backups stored onsite and offsite
  • Multi-factor authentication for administrative access
  • Vulnerability scanning and patching
  • Dallas is the preferred primary region

Every line item was reasonable. The job of our proposal was to demonstrate what each item meant in practice: what was included, what needed to be quoted, and what would be a one-time charge.

The Architecture: Two VMs Behind a Managed Firewall

Atlantic.Net proposed a two-VM HIPAA-compliant environment behind a FortiGate firewall-as-a-service. The first VM would run the Django application, and the second VM would run the database. Both would sit on a private network behind the firewall, a critical matter of separation.

The application VM is the part of the stack that needs controlled exposure to the internet. It receives web traffic, terminates TLS connections, runs the Django application, handles API requests, and accepts webhook requests. The database VM does not need to be exposed to the public internet. It’s only required network neighbors are the application VM and the approved management path via a customer VPN connection.

In the proposed environment, traffic from the internet first reaches the FortiGate firewall. The firewall inspects traffic and forwards only approved ports to the application VM. The database VM remains unreachable from the public internet. This is the practical difference between having the right list of security requirements and having an architecture that supports them.

The Application VM

The proposed application VM included 6 vCPU, 16 GB of RAM, and 200 GB of SSD storage. The sizing made it a comfortable starting point for an early production Django workload. It allows the application VM to run the reverse proxy, the Django application process, internal API services, webhook endpoints, and background workers without requiring additional infrastructure on day one.

A typical configuration would include Caddy or Nginx terminating TLS, with Django running behind Gunicorn or uWSGI. Background jobs could run through a queue, such as Celery or Redis Queue (RQ), on the same VM at this stage.

Splitting background workers or the reverse proxy onto separate VMs may make sense later, and is absolutely an option going forward for the customer. But right now, it was not required for the initial deployment.

The Database VM

The proposed database VM included 4 vCPU, 16 GB of RAM, and scalable block storage. For a Django deployment, PostgreSQL or MySQL would both be suitable. Atlantic.Net’s HIPAA-compliant hosting environment supports both database engines, so the final choice can align with the application team’s preference and existing development stack.

The important architectural point is that storage can scale independently of the VM size. That is critical for databases because storage growth and CPU pressure change over time. A database will typically need more disk storage long before it needs a larger compute profile.

By placing the database on its own VM, the customer gained a cleaner security model, a simpler auditing model, and more flexible scaling. It was a great balance that met the customers’ expectations from day one.

The Security and Compliance Layer

The BAA is signed before any ePHI enters the environment. For Atlantic.Net HIPAA-compliant hosting, the BAA is included as part of the tier and is signed prior to going live. It is not treated as a separate upsell and is embedded in the service we offer our healthcare customers.

At the edge of the environment, the FortiGate Firewall as a Service provides the managed perimeter. Intrusion prevention is enabled on the firewall, and traffic is restricted only to the application ports that need to be exposed.

The managed hosting package also includes bi-weekly vulnerability scanning and patching. Trend Micro Deep Security provides anti-malware and host-level intrusion detection on the VMs. Detailed access and administrative action logging runs on the firewall and VMs, providing the customer with audit traceability when required.

For administrative access, the proposal included five Duo MFA licenses. That covered the customer’s expected administrative users with some room to grow. Additional licenses can be quoted as needed.

VPN Connectivity

The RFQ requested VPN connectivity for external systems but did not specify whether the customer needed a site-to-site VPN, a client VPN, or both. The FortiGate firewall supports both models.

Client-based VPN gives individual administrators secure access into the environment. Site-to-site VPN connects the Atlantic.Net environment to an office, partner network, or external system. Atlantic.Net’s HIPAA hosting includes five VPN tunnels at no additional charge, so the customer did not need a separate tier to support the initial VPN requirement.

In this case, the customer later confirmed they needed a site-to-site VPN between the FortiGate firewall and an on-premise SonicWall. That is a common pairing, and the FortiGate can establish an IPsec tunnel with a standards-compliant peer such as SonicWall, with Atlantic.Net’s network team coordinating setup during provisioning.

Encrypted Backups in Two Locations

Daily encrypted backups were included for both VMs. Backups are encrypted at rest and stored in two locations. The local backup copy remains in the Dallas data center alongside the production environment. The off-site copy is stored in Atlantic.Net’s Ashburn, Virginia, facility.

Having a regional split is intentional; Dallas and Ashburn are separate fault domains. They operate in different physical locations, on different infrastructure, and under separate facility controls. That is what an off-site backup copy is supposed to provide.

For an early production environment, thirty-day retention is often sufficient, but we work with our customers to create an RTO that meets their needs. Customers with stricter internal policies, contractual requirements, or tighter recovery objectives can extend the design with longer retention, more frequent snapshots, streaming replication, or application-level replication.

Those enhancements are quoted as add-ons when required. They do not need to be built into the first deployment unless the recovery requirements demand them.

Region Choice: Dallas Primary, Ashburn Offsite

The customer preferred Dallas as the primary region, and Atlantic.Net operates a HIPAA-audited data center in Dallas that directly meets the requirement. Dallas became the production region. Ashburn became the off-site backup region.

For a customer with business operations and partners concentrated in the central United States, Dallas also made sense from a latency perspective. The application runs close to the expected user and partner base. The Ashburn copy is there for recovery, not for every production transaction. Having this distinction is important because the off-site backup location improves resilience without adding latency to normal application traffic.

Three Confirmations Before Provisioning

After accepting the proposed two-VM environment, the customer returned with three final questions. Each one was common, practical, and important enough to answer clearly before provisioning began.

Can the reverse proxy and Django run on the same VM?

Yes.

At the proposed VM size, running Caddy or Nginx on the same VM as Django is a normal starting pattern. The reverse proxy terminates TLS and forwards traffic to Gunicorn or uWSGI. The Django application then handles application logic, APIs, and webhook endpoints.

Splitting the reverse proxy onto another VM is possible later, but it was not required for launch.

Can the FortiGate connect to an on-premise SonicWall?

Yes.

The FortiGate firewall can support an IPsec site-to-site VPN with a SonicWall or another standards-compliant peer. The setup falls within the five included VPN tunnels. Atlantic.Net’s network team configures the FortiGate side during provisioning and coordinates with the customer’s SonicWall administrator to ensure a matching configuration.

Can the environment host multiple domains and subdomains?

Yes.

There are no infrastructure-level restrictions preventing the application VM from serving multiple domains, subdomains, or virtual hosts. TLS certificates can be issued through Let’s Encrypt using DNS or HTTP validation, or the customer can provide certificates if they prefer to manage them centrally.

None of these confirmations required a change to the quote. They were configuration decisions, not architecture changes.

What Was Included, What Was Quoted, and What Was One-Time

The proposal separated costs into three clear categories. The monthly recurring price covered the application VM, the database VM, the signed BAA, FortiGate Firewall as a Service, intrusion prevention, bi-weekly vulnerability scanning, managed patching, encrypted daily on-site and off-site backups with 30-day retention, 5 Duo MFA licenses, and 5 VPN tunnels.

The one-time charge was limited to a single item: a $150 onboarding fee for the FortiGate firewall. There were no other setup or onboarding fees.

Items quoted case by case included future scaling and post-launch add-ons. That could mean moving the application VM from 6 to 8 vCPU, increasing memory on the database VM, expanding storage, adding VPN tunnels beyond the included 5, adding Duo MFA licenses, extending backup retention, or introducing replication to achieve a tighter recovery point objective.

Why the Two-VM Split Was the Right Starting Point

A single-server Django deployment is technically possible. For a HIPAA workload, it is usually not the best starting point. Keeping the application and database on separate VMs gives the customer three immediate advantages.

  1. The database does not receive public internet traffic.
  2. The application cannot consume the same CPU and memory resources that the database depends on.
  3. Each tier can scale independently as usage grows.

The cost difference between a single-server deployment and a two-VM deployment at this size is modest. The compliance and operational benefits are much larger. That is why the proposal did not shrink the environment into one machine, even though the initial workload might have fit there. The two-VM design gave the customer a cleaner security boundary from the beginning.

From Signed Quote to Live Environment

Once the quote and BAA were complete, the deployment moved through a predictable sequence. Atlantic.Net provisioned the FortiGate firewall, built the VMs on the private network, applied the managed security controls, scheduled encrypted backups, enabled Duo MFA, prepared VPN connectivity, and coordinated the site-to-site tunnel with the customer’s network team.

From there, the customer’s application team could deploy Django onto the prepared environment. Having a division of responsibility is important for managed HIPAA hosting. Atlantic.Net handles the underlying infrastructure, perimeter security, backup framework, access controls, and managed services. The customer focuses on the application.

For teams building a Django, Rails, Node, or PHP application that will handle ePHI, the hard part is rarely naming the controls. Most RFQs already include the right words: BAA, firewall, MFA, VPN, backups, scanning, patching, and private networking. The harder part is turning those words into an environment that can be provisioned, managed, audited, restored, and scaled.

For this customer, that meant a Dallas-based two-VM Django deployment behind a managed FortiGate firewall, with a private database tier, encrypted onsite and offsite backups, Duo MFA, vulnerability scanning, VPN connectivity, and a signed BAA in place before ePHI entered the environment.

That is the difference between a HIPAA hosting checklist and a live production architecture.