After a decade of building and scaling production infrastructure, we’re just getting started

Today is Aptible's 10th birthday. Ten years is a long time to be in business. 

, somewhere around 90% of software startups fail. So why has Aptible been one of the lucky ones?

I believe it’s because we’ve stuck to our mission since the beginning, building and improving a core competency that our clients continue to love and want more of. We’ve delivered real features that so many companies need to solve their cloud infrastructure problems.

 that didn’t exactly turn out the way we expected, we never stopped doing what we do best. And now we’re focused on bringing our successful self-service features to more mature companies with growing engineering teams. 

It’s a tall order, but the solution is buried in our DNA. It’s only a matter of time before it comes out.

Aptible’s journey began in 2013, when HIPAA forced a whole new class of companies to become regulated businesses. We knew that thousands of digital health companies were about to have an instant compliance problem, and we really wanted to solve it for them. 

I was a software engineer who relished the challenge, and my co-founder, 

, had just ended his service in the U.S. Armed Forces as a regulatory lawyer at the Pentagon. While we came at the problem from different angles, we were both passionate about putting the puzzle pieces together. 

We had a very clear mission to simplify HIPAA for developers in healthcare. Developers are at the heart of innovation, and our goal was to keep compliance out of their workflow, so they never had to worry about it.

And we did it: we brought a platform to market that made HIPAA compliance achievable from day one. We were fortunate to cultivate a few instant clients, who we met while renting office space from Blueprint Health, a startup incubator in New York’s SoHo neighborhood.

In our early days, from the fall of 2013 to the spring of 2014, clients such as Hint Health, Aidin, Healthify, and ChartRequest helped us evolve our platform with a viable product. We quickly established Aptible as the go-to platform as a service (PaaS) for digital health startups, and soon began expanding our scope to support HITRUST, SOC 2, ISO 27001, and other compliance frameworks. 

In May 2014, Y Combinator accepted our application and gave us incredible guidance, along with exposure to investors and other clients. A 

 that summer was the match that ignited everything for us. 

From 2014 to 2018, we scaled entirely from inbound calls and referrals. It was a wild ride, and for the first two years it was all we could do to keep up with the growing demand. 

By 2018, things started to stabilize. Customers kept coming and we were very close to profitability. We had some breathing room to start thinking about what we were going to do next. 

Over all these years, we have continuously focused on supporting our customers’ evolving needs. It allowed our engineering to be 100% focused on delivering improvements to our core platform. And it’s paid off:

Considering the odds of failure in the startup world, I think we are in a fantastic place in 2024 and we’re positioned to do even better.

Building the future: How companies will manage cloud infrastructure

My amazing team at Aptible still believes strongly in the strength of the product we’ve been delivering since the spring of 2014. By improving developer self-service for our clients, we’ve helped them master their infrastructure more affordably and gain incredible advantages when it comes to cost and efficiency.

With that initial success and great feedback, we’re now working on delivering what we do for startups to more mature companies. 

To mature organizations, everything built for startups looks like a Fisher Price solution, and no one we know of has been able to build a viable developer self-service platform internally. As companies grow, infrastructure just naturally gets more complex and harder to maintain. It eventually gets to a point where there's a giant mess of infrastructure, with only the remaining “old-timers” truly understanding how and why things are the way they are. 

This is not a new problem. It’s cyclical and feels perpetual. Here’s what it looks like:

And yet, developers want new capabilities that implement the latest best practices. They want new services and automation to make their work less manual. It’s intense! Everyone wants to take away the pain with solutions like internal developer platforms, but it’s an immense undertaking.

A decade ago, we were passionate about helping healthcare startups instantly comply with HIPAA. Today, we bring that same fervent enthusiasm to solving a new problem: helping mature companies across all industries get control over their infrastructure. The answer isn’t “autonomous infrastructure” or AI-driven. It’s all about delivering developer self-service.

The answer has always been in the core of our product: giving users control over infrastructure to standardized golden paths that allow devs to quickly do what they need without compromising on security, compliance, reliability, performance, or cost.

We want to help DevOps teams know everything about their infrastructure and correct any problems they find. Here’s what that looks like:

We’ve laid the groundwork for a new type of platform and are testing it with our customers. We can’t wait to show you what’s coming.

We’re homing in on what it will take to help the vast swath of companies that are “too big for PaaS.” In recent months, we’ve been discussing the issue with companies who’ve come to a point of pain that’s motivating them to find something that works. 

We know that companies are shopping for solutions. Some organizations are combining point solutions like Vercel and Temporal. Others are implementing portal builders like Port or Cortex, or adopting an internal developer platform builder like Humanitec. We’re even seeing PaaS solutions embrace new models for extensibility (like Porter running on k8s in your own AWS account). A lot of investment and activity is taking place, but nothing is solving the problem successfully.

We understand, better than anybody, the infrastructure struggles plaguing large companies’ development teams. For hundreds of companies, Aptible has become the general-purpose platform the whole development team uses. Leveraging that hard-won knowledge, we are wholly dedicated to crafting an elegant solution that simplifies infrastructure management and empowers developers in any industry to remain singly focused on the kind of innovation that drives sustainable growth.

Looking back on the last decade, it’s clear that our journey to becoming the company we were always meant to be is just beginning. Here’s to another 10 exciting years!

10 Years of Aptible—Highlights from a Decade of Growth

Reflections and Lessons Learned from a Decade of Working with Hundreds of Scaling Companies

as an entirely new Aptible. This included a new look, new pricing plans, and a new UI. But more importantly, we reintroduced ourselves as a platform on a mission to give 

enterprise-grade infrastructure to engineering teams of all sizes.

 This year marked significant strides in enhancing our platform, making Aptible more powerful than ever.

To better support development teams of all sizes, we recognized the need to invest heavily in developer experience (DX)–from users just getting started on Aptible to power-users working in our platform on a daily basis.

Video

For users who are just getting started, we focused on the following in 2023:

For our everyday Aptible users, we focused on the following in 2023:

Our goal is to continue to evolve the Aptible platform to support the customization that scaling and enterprise dev teams need to innovate. To support this, we focused on the following in 2023:

Reliable infrastructure, delivered like magic ✨

You might hear Aptible referred to as the “No Infrastructure platform”. We think of this as a platform 

where you don’t have to think about infrastructure.

 It’s what our customers love about us most.

To support this, we focused on the following in 2023:

2023 has been an incredible year for Aptible, and we plan to carry that momentum in 2024. Are you excited for what’s in store? We certainly are! To follow along with what we’re building at Aptible and to request features that would benefit your team, visit 

In 2023, we reintroduced ourselves as an entirely new Aptible. This included a new look, new pricing plans, and a new UI. But more importantly, we reintroduced ourselves as a platform on a mission to give enterprise-grade infrastructure to engineering teams of all sizes. This year marked significant strides in enhancing our platform, making Aptible more powerful than ever.

 Aptible in 2023

A good user interface (UI) is not just about aesthetics. It plays a pivotal role in the overall developer experience. A thoughtfully designed UI abstracts away the complexity of the underlying systems and delivers intuitive interaction, clear visuals, and seamless navigation. And ultimately enables developers to focus on what truly matters: building, testing, and deploying quality code.

We’ll be the first to admit that the developer experience on our UI has been lacking, to say the least. But that ‘meh’ experience ends today. We've listened to your feedback and spent unknown hours refining our design and functionality to bring you a more intuitive, efficient, and visually appealing UI.

We're excited to introduce a host of new features that will make managing your deployments a breeze.

Our new UI streamlines the deployment process, giving users the ability to not only deploy their applications, but also manage configurations (previously only doable in the CLI), and seamlessly add additional endpoints and databases as needed. But that’s not all — users can now view real-time logs to debug any issue they come across, and re-run operations, all directly from the UI.

With our new UI, we’ve brought a responsive design that adapts to screens of all sizes, ensuring readability, functionality, and speed. We’ve also introduced a collapsible navigation menu and new sidebar that allows users to deploy new environments, and explore stacks, environments, apps, and databases within their organization.

Find what you need quickly and easily. Search for stacks, environments, apps, and databases by Name, Type, or ID. We’ve even added recently viewed and most visited sections to help you quickly locate your favorite resources.

The bulk of our redesign efforts fall into the category of pages. Pages are where the majority of interactions happen, questions are answered, and confidence is gained. We meticulously redesigned each page to simplify your deployment management tasks.

Yes, everyone says ‘this is just the start’ and rarely do any follow up. But, we’re going to buck the trend. We know the work is not done and that this is just the beginning. During this whole process, we kept on uncovering more and more areas and features we thought - hey that could be way better.

But, we’re still quite happy with where our UI has gotten to. We think it’s a significant leap forward in user experience and functionality, and we hope you feel the same. We can't wait for you to explore and use the enhancements we've introduced! And, we’d love any and all feedback you have as you use Aptible — you can easily share feedback with us from the UI, in the footer.

A Fresh Look at Aptible’s UI

One thing we all love at Aptible are t-shirts. These versatile garments are more than just a piece of clothing covering one’s torso — they're an expression of identity and a canvas for creativity. T-shirts have a unique way of showcasing our passions and affiliations to the world.

So we thought, why not take our love of t-shirts and combine it with what we’re doing here at Aptible. Our mission is to enable developers to do more with less infrastructure. We’re calling it the No Infrastructure future. Imagine, what if you didn’t have to manage infrastructure? What if you didn’t have to deal with the complexities of provisioning, the challenges of scaling, and the burden of infrastructure maintenance? There’s very few (although they probably do exist) that want to spend more time dealing with infrastructure.

Introducing our initial collection of ‘No Infra’ shirts. This collection serves as a tangible representation of shedding the burdens of software infrastructure.

To share our love of shirts and the ‘No Infrastructure’ movement, we’re giving this initial collection of shirts away for free. 

And, this collection of shirts will not be reprinted. Once they're gone, they're gone for good. So experience Aptible's platform and claim your shirt before it’s gone.

BlogCTA

👕 Deploy your first app and get a ‘No Infra’ shirt.

For any first time users, simply sign up for Aptible, deploy your first application, and you’ll receive a t-shirt.

Deploy a Shirt 👕

At Aptible, we get a lot of questions about HIPAA business associate agreements, or "BAAs." This post will explain some of the essential concepts that cloud-hosted software development organizations should know about BAAs.

One caveat, as always: This post is for informational purposes only. Aptible is not a law firm, and this post is not legal advice. You should contact an attorney to obtain advice with respect to particular issues or problems, including contracts and BAAs.

"BAA" is an acronym for "business associate agreement," which is an industry term for what the HIPAA regulations call a "business associate contract." Same thing. 

BAAs are hybrid contractual and regulatory instruments, meaning they both satisfy HIPAA regulatory requirements and create liability between the parties.

Like most contracts, if one party violates the agreement, the other party may have remedies. Unlike most contracts, if a BAA isn't in place, isn't complete, or is violated, both parties may be in trouble with the federal government.

The most common type of business associate is a person or organization that creates, receives, transmits, or maintains protected health information (PHI) "on behalf of" a covered entity or another business associate.

The regulations are more nuanced, but in the real world, if you handle identifiable patient data for any reason, most covered entities (healthcare providers, insurance companies, pharmacies, self-ensured employers, etc.) will consider you to be a business associate and make you sign a BAA.

What does it mean to handle PHI "on behalf of" another entity?

Good question. HHS hasn't actually told us directly. It probably means the other entity (a covered entity or another business associate) either pays you or directs you in handling PHI.

For two examples of HHS interpreting what it means to handle PHI "on behalf of" an entity for purposes of determining whether a business associate relationship exists, see 

No, members of your workforce are not your business associates, but you are responsible for supervising their access to PHI and training them on security and privacy practices. Your "workforce" includes paid employees, but also volunteers, trainees, temporary staff, and anyone else under your direct control.

Probably. Most of the time independent contractors and consultants will not be under your direct control and should be treated as business associates, meaning they need to be prepared to comply fully with HIPAA, including signing a BAA and accepting liability for compliance.

Any time a business associate relationship exists between two parties, they are required to execute a BAA. (Note that a BAA doesn't need to be a standalone agreement. The required provisions be can incorporated into terms of service, master service agreements, data security agreements, etc.)

There are two kinds of business associate relationships:

BAAs work like a chain: A covered entity customer of yours is not required to have a BAA with your subcontractor.

For example, if you sell SaaS that handles PHI to a large self-insured employer (a covered entity) and host your services on Aptible:

What does the BAA requirement mean for choosing our stack?

In addition to Aptible or another hosting provider, you probably use a range of third-party app and workflow services to build your products and run your business. For example, you might want to use Twilio for sending SMS, Mailgun for transactional email, Mixpanel for analytics, AWS RDS for your database, Papertrail for logging, Slack for internal communication, Gmail for email, etc. Some of those providers will sign BAAs, others will not.

Be careful to not have any vendor create, receive, transmit, or maintain PHI on your behalf without a BAA in place.

If they don't sign a BAA, keep PHI out of their service.

You might be tempted to use a service with PHI anyways, or look the other way. Don't do that. HHS just hit a healthcare system with a 

. Last year, HHS fned another covered entity 

(think Dropbox or Google Drive) for PHI without a BAA.

So if you want to use service with PHI but can't find a vendor who will sign a BAA, you may have to build that service yourself. Ugh.

In that case, self-hosting an open-source service on a private stack using Docker containers is becoming a popular choice. Among Aptible customers, 

are designed for portability to private environments.

What if a vendor signs a BAA, but I don't think they're really compliant?

Some version of the following conversation happens on a fairly regular basis:

Customer: I want to spend $MONEY on your service. Are you HIPAA-compliant?

Shady Vendor: Yes! Of course! We have all the HIPAAs.

If you know that a business associate of yours has materially breached a BAA, the HIPAA regulations say you must correct it or terminate the BAA. If you don't, you could be on the hook for the vendor's non-compliance. And it makes HHS very angry when entities ignore the HIPAA rules on purpose.

That said, HIPAA does not require that you police your vendors. When they handle PHI for you, they become directly liable for compliance and are subject to penalties and enforcement on their own.

The full requirements are in the text of the regulations. HHS publishes an "

" that presents all the HIPAA regulatory standards in one document. Look at §§ 164.314 (p. 67) and 164.504 (p. 81) in particular.

with a list of the 10 topics that BAAs must address and sample provisions - defnitely recommended reading.

In very brief summary, the main requirements for a BAA are to:

What are other common terms to fnd in a BAA?

Strict inheritance of all BAA terms by subcontractors

Part of the Privacy Rule says that subcontractors business associates must "agree to the same restrictions and conditions that apply to the business associate with respect to such information."

Some entities misunderstand this to mean that all provisions of all BAAs down the chain must be identical, including custom security controls. This is wrong and unnecessary.

The intent of the rule is to make sure a business associate can't end-run privacy restrictions by contracting out to a third party. If the business associate isn't allowed to perform a use or disclosure, their subcontractors aren't either.

Security is a separate matter. The Security Rule has its own set of organizational requirements, which do not include strict inheritance of controls. That makes sense in light of the Security Rule's emphasis on flexibility and application of controls that are "reasonable and appropriate" to each entity.

It is fairly common for covered entities to push for very short breach reporting triggers and timelines. Sometimes this is driven by the mistaken belief that the covered entity has 60 days from the time
of the frst discovery of the breach by anyone to complete its Breach Notification Rule obligations.

Breach reporting runs in serial, not parallel. (See 

Don't agree to report breaches "within $X days" of the breach. You can't - odds are you may not even know there was a breach by then. Use the "known or should have known" threshold in the Breach Notification Rule.

Requiring subcontractors to be legal agents

An "agent," in the legal sense, is someone who acts as you. For the purposes of breach notification, an agent's discovery of a breach is imputed to you, as are the legal consequences of their actions. Almost every subcontractor or vendor agreement expressly disclaims an agency relationship between the
parties. A BAA that requires all of your subcontractors to be your agents is unnecessary, dangerous, and probably impossible to comply with.

Always talk with an attorney to understand your potential liability. Liability and indemnification provisions may appear both in your underlying contract and your BAA - make sure you understand how they work together, and which terms control in the event of a confict. For startups, contracts with no limitations on liability will make you toxic to potential acquirers.

Liability has both breadth and depth. Breadth, or scope, means the types of damages that you might be liable for. In general, you should only accept certain types of liability. Unlimited liability means that, in addition to any breach indemnification, your customers could also potentially sue you for loss of
business, loss of reputation, and other consequential damages. It is common to exclude those types of liability.

Depth refers to how much you might potentially be liable for. Another way to limit liability is through a total dollar cap. This is common for general liability (i.e., if you don't hold up your end of the underlying contract), but uncommon for breaches, where the normal practice is uncapped indemnification. This isn't as bad as it sounds because the types and amounts of costs involved in breach response are somewhat
predictable and insurable.

Feel free to incorporate parts of these examples into your own BAAs, but 

always consult an attorney for specific legal advice.

If you have any questions about this post, or you'd like to chat about how to design and scale a HIPAA-compliant engineering organization in the cloud, feel free to 

What is a HIPAA BAA?

Explosive growth in digital health over the last few years means there are many developers and managers who haven’t worked under HIPAA before. This article is written for startups (and small businesses operating online) who could use some help with the basics of HIPAA compliance.

This post is lengthy, but if you read it all, by the end you will have a solid understanding of HIPAA, compliance with HIPAA requirements, and how all of this will aﬀect your engineering organization.

One caveat: This post is for informational purposes only. Aptible is not a law ﬁrm, and this post
is not legal advice. You should contact an attorney to obtain advice with respect to any particular issue or
problem.

HIPAA is a federal law that protects the privacy and security of health data. It is enforced by the
Oﬃce for Civil Rights (OCR) of the U.S. Department of Health and Human Services(HHS).

HIPAA was passed in 1996 and updated by a law called HITECH in 2009. In 2013, HHS
published a large administrative "Omnibus" rule to implement HITECH. For our purposes,
HIPAA, HITECH, and the Omnibus Rule all refer to the same concept: The HIPAA regulations.

The HIPAA regulatory rules are, in practice, the most important aspect of HIPAA because they deﬁne the obligations of regulated entities and penalties for non-compliance. When we talk about "HIPAA compliance," we are referring to compliance with the regulatory rules.

The HIPAA regulations apply to organizations, not products or features. A company can say it is “HIPAA compliant”, but it doesn't
make sense to refer to a product that way.

If you are regulated, HIPAA requires that you ensure your organization:

That is a drastically simpliﬁed summary, of course. In practice, the requirements are more complicated. The 

 U.S. Department of Health and Human Services (HHS) used for its ﬁrst round of audits has
several hundred "key activities," most of which contain several audit procedures. The most challenging part of a good HIPAA compliance program is being able to prove to an auditor or OCR enforcement agent that you did everything you were required to, and that you made reasonable decisions along the way.

HIPAA's formal name is the Health Insurance Portability and Accountability Act of 1996. HIPAA
has a special limit: it only regulates entities that handle data that has been (or will be) related to a health insurance transaction.

HIPAA divides regulated entities into two categories:

Business associate relationships can form a chain, usually when multiple sub-vendors are needed to provide a service. This is very common in cloud-based SaaS.

 is a team communication platform for healthcare professionals. Doctors and other providers can chat, send private messages, and share pictures, video, and ﬁles with each other. Stitch has a freemium model where larger customers pay for advanced features. Stitch runs on Aptible, which in turn runs on AWS.

In this example, Stitch's customers are usually covered entities. Stitch is their business associate, because
Stitch handles PHI on their behalf. Stitch in turn has several business associates, including vendors like Aptible. For a typical Aptible customer, AWS is Aptible's business associate. Aptible customers don't need to execute a BAA
with AWS unless they want to use a HIPAA-eligible AWS product on their own, such as S3.

To determine whether your speciﬁc organization is regulated, you should consult an attorney.

What data do we need to protect under HIPAA?

To be regulated, health data must be individually identiﬁable and contain health information. Together, this would be what HIPAA calls "protected health information" (PHI). General personally identiﬁable information (PII) alone is usually not enough, but this can be tricky: PHI is a very, very broad category.

Protected health information is information, including demographic information, which relates to:

Protected health information includes many common identiﬁers (e.g., name, address, birth date, Social Security Number) when they can be associated with the health information listed above.

PHI is broader than just health insurance transaction data. HIPAA is like a springing trap - it hooks you, then expands to cover much more data than the hook.

Who will check if we are HIPAA compliant?

Can we be ﬁned for HIPAA violations where there is no
breach of PHI?

Yes, HHS can impose ﬁnes for violations of any provision of the HIPAA rules, not just ones that
result in breaches.

Breaches are the only violations with reporting requirements, but HHS may investigate any complaint that a covered entity or business associate is not complying with the HIPAA regulations. That said, OCR usually reserves ﬁnes for cases where a breach occurs. HHS has the discretion to determine the amount of a penalty, up to certain limits, and must consider factors such as the nature and extent of the harm resulting from a violation. Breaches are more likely to cause serious harm, whereas other violations may be less harmful.

The dumb answer is just "follow the HIPAA rules." If you comply with the rules, then you are "HIPAA compliant." Duh.

 There are several problems with the dumb answer:

A better answer to "How do we become HIPAA compliant?" might be:

You will probably want help with this at some point. You can hire in-house, hire a consultancy, buy a product/service (such as Aptible), or some combination of those.

HIPAA has three main “rules,” or sets of regulations, that specify how regulated organizations need to operate and handle PHI. HIPAA actually has more rules, but most of the time when we use the phrase “HIPAA compliance,” we are referring to these three.

 applies to PHI in all forms (oral, written, electronic, etc.), and covers
issues such as:

 applies only to electronic PHI. It contains requirements for administrative, physical, and technical safeguards. It also requires published policies and procedures that document how you select and enforce those safeguards. You must retain documentation and evidence of your Security Rule compliance for six years.

For many engineering organizations, the Security Rule is the hardest, most burdensome part of HIPAA. It can also be confusing: The rule is divided into “standards,” which are required but often vague, and “implementation  speciﬁcations,” which are either required or “addressable” and usually not much more speciﬁc than the standards. HHS is working on collecting questions from digital health developers, but ﬁrm guidance and best practices are still hard to come by.

In order to help you understand how the Security Rule may apply to a cloud-based SaaS team, we've included the following questions and notes. You can read the 

Management controls, encoded in policies and procedures, related to how you select and implement a security management program, including risk management.

Controls to protect the physical facilities, computers, and devices that house PHI, such as data centers, oﬃces, laptops, thumbdrives, workstations, etc. Most cloud-deployed SaaS companies try to limit their physical footprint, in terms of handling PHI. Speciﬁc scoping measures might include prohibiting your team from downloading or persisting PHI to laptops, phones, and portable media.

Controls implemented through engineering processes. The technical safeguards contain elements of privacy and security by design, and should be incorporated as early as possible into your technical design process.

In many cases, your BAA with a larger customer will be more stringent than what the Breach Notiﬁcation Rule requires. For example, you might have to report breaches sooner than 60 days following your discovery of the breach.

The Breach Notiﬁcation Rule also contains the rules under which unauthorized access to encrypted PHI can be excluded from being a reportable breach.

You now know just enough about HIPAA and how to become compliant to be dangerous. As you plan out your go-to market strategy, you'll be able to identify potential issues before they arise. If you'd like to chat about how to design and scale a HIPAA compliant engineering organization in the cloud, feel free to 

HIPAA Compliance Guide for Startups

We are excited to announce that we’ve completely refreshed our 

 Taking into consideration both user feedback and industry best practices, we’ve redesigned the site to provide users with a
more intuitive experience and rewrote our docs to ensure that it is clear and
concise.

One of the biggest changes we made is the complete restructuring of the docs
site. We simplified the navigation, making it easier for users to find the information they need. The 

 served
as inspiration with its four distinct categories—Tutorials, How-to Guides, References, and Explanations—that serve to provide clarity to both the author and the reader. Using this framework as a guide, we implemented our own new categories:

Based on feedback from our new and existing users, we have rewritten most of
our docs to improve overall clarity. We recognized that some of our docs
covered advanced DevOps topics, which led engineers to search for additional
resources. With the rewritten docs, we aim to address this issue by providing
comprehensive explanations that don't require users to seek external information. Our goal is to equip our users with all the knowledge they need within our docs itself.

 to align with our new Deploy Code from the Dashboard release. This exciting feature allows users to deploy a Starter Template directly from the Aptible Dashboard, simplifying
the deployment process. The updated Starter Guides will guide users through the new workflow step-by-step, ensuring a smooth onboarding experience.

To enhance the search experience, we implemented an improved search
functionality that includes preview text. Users can now get a glimpse of the content before diving into the full document, making it easier to find the information they’re looking for.

We restyled our doc site last month, but to further enhance the visual
experience, we have added over 40 reference images throughout our docs. These
visuals aim to clarify concepts, illustrate workflows, and give users visual
cues to navigate the Aptible Dashboard.

But that's not all! We have also introduced new widgets to our docs site, making it even more convenient for users to engage with our platform. You can now 

 within the docs itself. Additionally, we've connected our status page to our docs site so that in the event of an outage, a notification will display directly in our docs.

We are thrilled to present these updates to our docs site, and we believe that
they will greatly improve your experience as you explore our platform. Our commitment to providing clear, concise, and user-friendly docs remains unwavering. We hope that these changes will empower you to make the most of
our services without any hurdles.

! We welcome
all your feedback on our new doc site. If you have any suggestions or ideas for further improvement, 

We’ve redesigned our docs site to provide users with a more intuitive experience and rewrote our docs to ensure that it is clear and concise.

A Closer Look at the Relaunch of Aptible Docs

At Aptible, we’re creating the No Infrastructure future. If we have our way, every developer will be able to provision and manage scalable and reliable apps and databases without becoming an infrastructure expert, earning a special certification from AWS, or getting their Ph.D. in Kubernetes.

As outdoor enthusiasts, we're also committed to protecting the environment.

This Earth Day, we're combining our mission with our love for nature. For every developer who signs up and deploys an app on Aptible, we'll plant 25 trees 🌳.

Experience Aptible's platform and contribute to a greener world.

Eden Reforestation Projects

 to plant trees from April 21st to May 22nd, 2023. Sign up below with your work email—no credit card required. Let's make an impact, one tree at a time.

🌳 Plant 25 Trees for Earth Day 2023

In honor of Earth Day, Aptible is planting 25 trees for every developer who signs up and deploys an app on Aptible. Let’s grow a forest together. 🌲🌳🌲

Deploy the Trees 🌲

Aptible has a new look. But more importantly, we want to talk about the future of platform as a service, and how we intend to rapidly expand the value our platform delivers to you. Also, it’s the Aptible platform’s birthday!

You might’ve noticed a few changes on aptible.com, in our docs, and in our product. Our visual design, how we talk about ourselves, our pricing page, and the product dashboard. What’s going on you ask?

Aptible has been fortunate to experience steady growth in our user base for the last 10 years, thanks primarily to the resilience and growth of our customers. Today marks the Aptible platform’s 9th official birthday. It also marks the beginning of the future for Aptible.

We’re proud of how far we’ve come since the platform launched on March 21, 2014. But there’s so much more ground to cover if we’re going to achieve our vision of making it possible for any developer and company to launch and scale products without building and managing infrastructure.

Over the years we’ve gotten countless suggestions and ideas on how to improve our PaaS. The most useful source of feedback has been the hundreds of calls we’ve had with existing customers, and the many we’ve had with prospective customers as well. We intend to continue these discovery processes and, in fact, we intend to accelerate our pace of learning further.

Today’s changes are just a step in that direction. While we plan to rapidly expand the value our product provides to customers, and to iterate quickly, what we are “soft launching” today is just the first in a long line of changes we anticipate making. All with the same end goal in mind: continually improving how we eliminate the pains of building and managing infrastructure for companies like yours.

Upcoming changes that we’re particularly excited about are:

But that’s just three changes. What’s guiding our focus moving forward?

While we’ve long delivered different user interfaces for our PaaS–CLI, Terraform, Dashboard–the developer experience, especially of our Dashboard, has become a bit dated. It certainly wasn’t the “magical” experience developers expect, or the one we want to deliver to make good on our promise to eliminate the pains of building and managing infrastructure.

We’re just at the beginning of this journey to deliver a magical developer experience. Our team is completely reimagining how developers use Aptible, making it more like this: 

At the same time, we continue to tackle the really hard scaling problems we’ve worked with hundreds of fast growing companies to solve. Problems such as: optimizing resource costs via autoscaling, right-sizing, and instance class tuning, deploying complex architectures just as easily as monolithic web apps, and finding and fixing performance bottlenecks in distributed systems.

Building for all startups–and every company

Hundreds of digital health companies have used Aptible to go from 2 developers in a garage to unicorn status, successful acquisition, and even IPO. But few outside of digital health know of Aptible. 

Aptible has great security and compliance benefits that are, in truth, industry agnostic. While we’ll continue to ensure we’re the best PaaS for digital health startups, we know our PaaS can be useful to every startup, regardless of industry focus.

Blog: Company

Reflections and Lessons Learned from a Decade of Working with Hundreds of Scaling Companies

Aptible in 2023

A Fresh Look at Aptible’s UI

Deploy a Shirt 👕

What is a HIPAA BAA?

HIPAA Compliance Guide for Startups

A Closer Look at the Relaunch of Aptible Docs

Deploy the Trees 🌲

Aptible’s New Look, and the future of PaaS

What’s new with Aptible: Feb 2023

What’s new with Aptible: January 2023

What’s new with Aptible: October 2022

What’s New With Aptible: September 2022

Improve Your Security Posture and Pass Audits with Aptible's New Compliance Visibility Dashboard

Greater focus on Deploy as Comply becomes Conveyor

Announcing Log Drain Improvements for High-Performant, Reliable Delivery to External Destinations

Aptible’s Response to COVID-19

Announcing Aptible’s $12 million Series A funding!

Introducing Aptible’s new brand identity

Aptible Enclave and Gridiron are HITRUST CSF Certified

Aptible SOC 2 Type 2 Report Now Available

Recap: Aptible January 2018 Quarterly Product Update Webinar

Meltdown and Spectre are Critical Vulnerabilities for Cloud Infrastructure. Here’s How the Aptible Security Team Responded

Recap: Aptible October 2017 Quarterly Product Update Webinar

Announcing ISO 27001 Certification for Aptible Enclave and Gridiron

Recap: Aptible July 2017 Quarterly Product Update Webinar

Recap: Aptible April 2017 Quarterly Product Update

Aptible was not affected by Cloudbleed

Aptible Powers PRIDE Study iOS App

How to Get Into Y Combinator

Hello World

Building a developer
platform is a thing of
the past.

Product

Resources

Support