To continue our series of request-for-quote deep dives, today we are going to look at a recent query we received. Some HIPAA hosting requests arrive as a short question; others (like this) arrive as a detailed technical checklist.

The customer was considering Atlantic.Net for HIPAA-compliant hosting and wanted to schedule a technical meeting. Before meeting, they sent over their intended setup, technical requirements, and questions.

From a pre-sales engineering perspective, this is extremely helpful, as it means the initial discussions can quickly move to scope, ownership, pricing, support boundaries, and any design risks that need to be addressed before production.

This customer required a HIPAA-compliant hosting solution that includes PostgreSQL, RabbitMQ, PHP 8.2, Redis, Postfix, Node.js, Chromium, Puppeteer, supervisor, systemctl, daily backups, storage encryption, IPS, firewall controls, two-factor authentication, integrity monitoring, immutable logging, and documentation.

That is a lot of detail, but it’s a checklist that the Atlantic.Net HIPAA hosting platform was designed for. Our job is to turn the checklist into a scalable production hosting scope.

The Starting Point

The customer’s environment was split between QA, staging, and demo environments. These were already running with another provider. Production was the environment being considered for Atlantic.Net.

This approach provided a sensible starting point for the conversation. We did not have to assume every environment was moving on day one. We could focus first on the production workload, then decide later whether to include non-production environments.

First, we needed to understand if the QA, staging, or demo contained any patient health information (ePHI), production data, production logs, credentials, or anything derived from real patient records?

If the answer is yes, those environments may require the same level of compliance attention as production. If the answer is no, we can scope production first and leave the other environments as they are for now. As a compliance leader, our engineers needed to understand the bigger picture so we could advise this potential customer in the best possible way.

The Initial Hardware Target

The customer listed a current configuration of:

  • 4 CPU
  • 8 GB RAM
  • 60 GB SSD

This was a useful starting point for pricing, but sizing still needs to be checked against how the application was expected to behave in production. Stacks like this have several moving parts. PostgreSQL, RabbitMQ, Redis, PHP, Postfix, Node, Chromium, and Puppeteer can all compete for CPU, memory, storage, and I/O.

For a modest production launch, some of those services may run on a single VM. That can keep the first deployment simple and cost-effective. For a busier workload, separation may make more sense. PostgreSQL may deserve its own resources. Puppeteer workers can be memory-intensive, and RabbitMQ and Redis may need closer monitoring depending on queue volume, persistence requirements, and how the application handles background jobs.

The Application Stack

The customer’s application stack was specific:

  • PostgreSQL for the database.
  • RabbitMQ for message handling.
  • PHP 8.2 for the application.
  • Redis for caching or queue support.
  • Postfix for mail flow.Node, Chromium, and Puppeteer for worker tasks.
  • supervisor and systemctl for process control.

Our engineers have no concerns about hosting the stack, but there are many important questions about ownership that we need to ask the customer.

  • Who installs each service?
  • Who patches it?
  • Who monitors it?
  • Who restarts it if it fails?
  • Who tunes it when traffic grows?
  • Who reviews logs when something behaves unexpectedly?

These questions needed to be answered before the order is signed, not during an incident. In many cases, Atlantic.Net provides the HIPAA hosting foundation while the customer manages the application stack. If the customer wants Atlantic.Net to manage specific services, those services need to be quoted, included in the scope, and provided by Atlantic. Net-managed services.

HIPAA compliance relies on shared ownership to be successful, and part of that is having clear boundaries that protect both teams. The customer knows what support Atlantic.Net would cover, and the customer’s in-house team knows what it is responsible for, and the application team knows what remains under their control. Drawing this line in the sand is essential to creating a service that serves everyone’s needs.

The Deployment Pipeline

One particular area the customer needed advice on was how their current CI/CD pipeline model would fit with HIPAA compliance. Should GitLab and the deployment procedure be HIPAA-compliant?

The best answer is: it depends on what the deployment process can access.

If GitLab or the deployment pipeline stores production credentials, pushes code into the HIPAA environment, contains secrets, generates logs with sensitive data, or gives users access to production systems, then it needs to be included in the compliance discussion.

That does not automatically mean GitLab has to be hosted by Atlantic.Net. But it does mean the deployment path should be documented and controlled.

A few practical questions help clarify the risk:

  • Where are production secrets stored?
  • Who can deploy to production?
  • Are deployments approved or automatic?
  • Do build logs contain PHI or sensitive configuration?
  • Do runners connect directly to the production environment?
  • How is deployment access removed when an engineer leaves?

A HIPAA hosting environment can be well-designed, but a careless deployment process can still pose a risk. That is why the deployment pipeline belongs in the pre-sales conversation.

Backups and Recovery

The customer asked about daily on-site backups, a recent off-site backup, and possible RTO/RPO expectations. The customer needed to know what is backed up, how often it is backed up, where the backup copy lives, how it is protected, and what a realistic recovery expectation is.

For this stack, the recovery discussion should be broken down by component. PostgreSQL is likely the most important recovery target. RabbitMQ may matter if queued messages cannot be lost. Redis may or may not require persistence, depending on how the application uses it.

Application files would need to be restored on the server. Logs mattered for compliance, troubleshooting, and incident response. Puppeteer jobs may also create files or artifacts that need retention.

A daily backup model would be suitable for the first production environment. Still, if the customer needed a tighter recovery point objective, a separate architecture discussion involving database-level backups, replication, disaster recovery planning, or a more advanced recovery design may be needed.

The important point is simple: recovery expectations should be defined before production goes live.

Security Controls

The customer’s security list included vulnerability scans, storage encryption, IPS, firewall controls, integrity monitoring, two-factor authentication for OS accounts, immutable logging, OS compliance audits, and setup documentation. These are all services available in the Atlantic.Net Managed service offerings.

Most of these controls are part of the hosting layer; others need to be configured inside the operating system. Some depend on how the customer manages the application and may require additional managed services.

For example, “firewall” sounds straightforward until we define ports, source IPs, VPN requirements, administrative access, and change control. “Immutable logging” sounds straightforward until we define which logs are shipped, where they are stored, who can access them, how long they are retained, and whether the application itself logs PHI.

“Two-factor authentication” also needs detailing. Does it apply to portal users, VPN users, OS users, application administrators, or all of the above?

Regional Scope and Pricing

The customer asked about support for at least the EU and U.S., with Asia as a nice-to-have. They also asked for pricing for the full configuration and pricing for only the U.S.

For a first production deployment, it usually makes sense to quote the cleanest required footprint first. If U.S.-only production is enough for launch, quote that clearly. If an EU deployment is mandatory, scope it as a separate regional design. If Asia is only a future possibility, keep it out of the initial production quote unless there is a real launch requirement.

What Needs to Be Decided Before the Quote

By the end of this kind of pre-sales review, the customer should be able to answer a few key questions:

  • Is Atlantic.Net hosting only production, or also QA, staging, and demo?
  • Do any non-production environments contain PHI?
  • Will all services run on one VM, or should some be separated?
  • Which services does Atlantic.Net manage?
  • Which services does the customer manage?
  • What backup cadence is acceptable?
  • What RTO and RPO does the business actually need?
  • Which security controls are included in the standard HIPAA hosting tier?
  • Which requirements need a custom scope or documentation?
  • Does the deployment pipeline need additional compliance controls?

From Checklist to Production Scope

The customer did the right thing by sending a detailed technical checklist before the technical meeting, and we were delighted to onboard them onto Atlantic.Net’s HIPAA-compliant hosting platform recently.

That early detail allowed our engineering team to treat the request as a real production environment, not just a collection of software packages. PostgreSQL, RabbitMQ, PHP 8.2, Redis, Postfix, Node.js, Chromium, Puppeteer, supervisor, backups, firewall rules, MFA, logging, monitoring, and documentation all matter. But in a HIPAA environment, the larger question is how those components are hosted, secured, supported, monitored, backed up, and managed over time.

This is where Atlantic.Net’s HIPAA-compliant hosting platform becomes the foundation. The production environment can be built on an audited, HIPAA- and HITECH-ready infrastructure, supported by a HIPAA Business Associate Agreement (BAA), secure cloud or dedicated hosting, encrypted storage, managed firewall protection, intrusion prevention, vulnerability scanning, log management, multi-factor authentication, encrypted backups, VPN access, and disaster recovery.

If the customer wants Atlantic.Net to provide the compliant infrastructure while their internal team manages the application, that boundary can be clearly documented. If they want Atlantic.Net to take on more operational responsibility, managed services can be added to the design, including server management, managed firewall, MFA, Trend Micro Deep Security, Network Edge/DDoS protection, managed Veeam backup, load balancing, migration services, consulting, database hosting, database administration, backup management, patching, troubleshooting, performance tuning, and high availability planning.

For this customer, that meant the proposal was not simply about quoting CPU, RAM, and storage. It needed to define the production region, VM sizing, security controls, backup model, access controls, deployment assumptions, support boundaries, documentation requirements, and any optional managed services required to operate the environment safely.

Have a HIPAA hosting checklist that needs to be turned into a production-ready scope? Contact Atlantic.Net to review your application stack, security requirements, backup model, and managed hosting options.