the reality for founders
The compliance problem shows up at the worst possible moments
Most founders building regulated products don't run into HIPAA as an abstract concept. They run into it as a specific problem, usually when something is already on the line.
Your first healthcare customer wants to move forward, and just sent a security questionnaire
The questions seem reasonable: where does PHI live, who has access, how long are logs retained, what isolation exists between environments. But finding clean, defensible answers requires reconstructing decisions made months ago under time pressure. The questionnaire sits in someone's inbox while the deal waits.
You made early infrastructure decisions fast, and you're not sure they'll hold
Networking, isolation, access controls, and logging got set up to ship quickly. At the time, the priority was getting the product running, not anticipating what an auditor or enterprise security review would eventually ask. By the time those questions arrive, the architecture is already in production and harder to change.
Compliance knowledge lives in one person's head
One engineer (often whoever built the initial infrastructure) understands why certain decisions were made and how access actually works. That knowledge isn't documented, it isn't enforced automatically, and it doesn't transfer cleanly as the team grows. Compliance posture starts to drift the moment a second engineer touches the system.
You want to add AI features but aren't sure how to do it safely
LLMs can meaningfully improve your product. But sending PHI to a model input without a BAA, or letting developer tooling touch production data, creates exposure that won't be visible until someone asks the right question. The easy path and the compliant path are often different, and it's not always obvious which is which.
Why founders get stuck
General-purpose infrastructure wasn't built for regulated workloads
Get to production with your first healthcare customer
Deploy on infrastructure that already meets HIPAA technical requirements. No need to design networking, encryption, or access controls before you can start handling PHI.
Answer the security questionnaire that just arrived
Pull audit logs, access records, and infrastructure documentation directly from the platform. Clean, attributable answers. No reconstruction required.
Bring on engineers without losing compliance continuity
New team members deploy and operate within the same controls that were in place from the start. Compliance posture doesn't degrade as the team grows.
Add AI to your product without opening new compliance exposure
Route LLM requests through Aptible AI Gateway to keep PHI inside controlled infrastructure boundaries. Logging and PHI guardrails are enforced automatically.
FAQs
How much should an early-stage startup expect to spend?
For PHI-handling production apps and databases, expect the Production plan at \$499 per month plus infrastructure usage. Early-stage teams often land in the high hundreds to low thousands monthly all-in, depending on containers, databases, disk, backups, endpoints, and availability requirements. Standard support is included at no cost.
If youโre a startup or in YC, the Startup Program offers discounted infrastructure for your first six months. The cost estimator on the pricing page will give you a number for your actual architecture.
Can I start building before I have customers or PHI?
Yes. Start on the Development plan, which has no base fee, and build in a non-PHI environment. When youโre ready to handle PHI, move your apps and databases onto a dedicated stack on the Production plan and execute a BAA. Support can migrate existing resources for you.
The LLM Gateway is an exception: its BAA covers all LLM Keys, so you can prototype AI features against PHI without a dedicated stack.
Do I need to hire a DevOps or compliance person to use Aptible
Not just to get started. Aptible is designed to reduce the amount of DevOps and compliance operations work your team needs to manage directly. Aptible handles the platform, database operations, security configuration, and compliance evidence layer, including host health, hardware maintenance, container recovery, patching, backups, and required infrastructure controls on dedicated stacks.
Aptibleโs reliability documentation explains the platform-level work Aptible manages, and Aptibleโs HIPAA documentation explains how HIPAA-ready infrastructure controls are applied on dedicated stacks.
Your team still owns the parts specific to your application and organization: application security, access controls, dependency management, policies, workforce training, risk analysis, vendor management, and final compliance decisions.
Many teams start on Aptible without a dedicated DevOps or compliance hire, then add specialized help later as their product, customer requirements, audit scope, or internal processes become more complex.
What's still my responsibility for HIPAA?
Your company owns application behavior and PHI handling in code, access control inside your app, organizational policies, workforce training, risk analysis, incident response, and vendor management.
Aptible handles infrastructure-level controls for resources running on Aptible.
What should I tell investors, customers, and design partners about our infrastructure compliance?
Point to artifacts rather than adjectives. Say your infrastructure runs on Aptible, a HITRUST-certified platform enforcing 100% of HIPAAโs required infrastructure controls, under a BAA, with evidence available on demand.
Then back it with the Shareable Compliance Posture Report from your dashboard, which shows each implemented control against the resources in scope
For reviewers who want Aptibleโs own evidence, the SOC 2 Type 2 report, Penetration Test Summary, and HITRUST certification are available through trust.aptible.com under NDA. Aptible also publishes guidance for security questionnaires and audits, and the Security & Compliance overview summarizes available evidence.
What happens to our apps and data if we need to move off Aptible?
Your apps are containerized, so they run anywhere, and your data exports with native tooling like pg_dump or mysqldump. That makes migration feasible.
One caveat: Aptible-managed backups are encrypted volume snapshots that depend on Aptibleโs database image and restore tooling, so they canโt be exported, mounted, or restored outside Aptible. If portability matters, maintain native exports rather than relying on backups.
If youโre deprovisioning but need to keep Aptible-managed backups for compliance, contact support beforehand so automatic backups can be converted to manual ones, because automatic backups are purged on deprovision unless your final-backup policy retains them.
If youโve set up S3 Log Archiving, that bucket is yours and the retrieval CLI works independently of Aptible, so archived container logs stay accessible after you leave. Aptible also documents the aptible logs_from_archive command for retrieving archived logs.
