Isolated application infrastructure
Each application runs in its own isolated environment, so mistakes in configuration or access cannot affect other systems. Full network isolation is a single step; creating a dedicated stack gives you complete network isolation with no additional configuration required. Isolation is enforced at the infrastructure layer and maintained automatically as applications scale.
Single control plane for access control and auditability
Control who can deploy, inspect, modify, and SSH into applications using built-in roles. Every interaction (deploys, configuration changes, app access) is logged and attributable in one place, without stitching together CloudTrail, CI logs, and OS-level audit logs separately.
Secrets and configuration handled safely
Manage application secrets and configuration centrally so credentials never live in code, CI pipelines, or ad hoc scripts. Enforce secure handling by default without custom tooling or manual processes.
Production-ready deploys without configuring AWS
Deploy via git push, Docker, or Terraform on isolated, zero-downtime infrastructure. No VPCs, load balancers, IAM policies, or security groups to configure, and production security and compliance requirements are met by default.
Operate without a platform or SRE team
Operate production applications without owning patching, infrastructure updates, or platform maintenance. Aptible handles the underlying platform so teams donโt have to become accidental platform engineers as systems grow.
View docs
Launch regulated applications without retrofitting compliance later
Teams building digital health or regulated products choose Aptible to deploy applications on infrastructure where the right controls are already in place.
Replace lightweight PaaS tools before they become a liability
Heroku and similar platforms work until a healthcare customer or enterprise buyer asks about isolation guarantees, audit trails, or BAA coverage. At that point the platform can't answer. Teams move to Aptible to close that gap without taking on AWS directly.
Avoid building an internal platform or security function too early
Early-stage teams choose Aptible to operate production applications safely without hiring a platform team or becoming responsible for long-term infrastructure security and compliance themselves.
FAQs
Can I host both my frontend and backend on Aptible?
Yes. Aptible can run frontend servers, backend APIs, admin apps, internal tools, and other containerized services, as long as they run in Docker containers.
You can expose services through an HTTP(S) endpoint with managed TLS and a custom domain, and add IP filtering if you need to restrict access.
If the frontend stores, processes, or transmits regulated data, include it in your compliance review.
What kinds of applications run on Aptible?
Aptible runs Linux-compatible dockerized apps serving HTTP, HTTPS, TCP, TLS, or gRPC traffic. You can deploy using Git, a Docker image, or Terraform.
Apps can define multiple services. Container filesystems are ephemeral by default, so durable data belongs in a managed database, object storage, or a Persistent Disk. SSH session containers are ephemeral.
Can I run background workers, scheduled jobs, and multiple services from one app?
Yes, you can do all three.
Multiple services: An app can have several services. Define them in a Procfile, with one command per service. Each service scales independently. Without a Procfile, the app gets a single implicit service. See Services docs.
Background workers: Run background workers as separate services in the same app. Common service types include web, worker, and api; each can have its own command and scaling configuration.
Scheduled jobs: Use cron through Supercronic, Aptibleโs open-source cron runner. Run scheduled jobs as a separate service, either in the same app or in a separate app depending on how you want to deploy and scale them. See the scheduled tasks guide for more info.
How do deploys, rollbacks, and scaling work?
Aptible supports deploys, rollbacks, and scaling at the service level, so a web service, worker service, and api service can each use different container sizes and container counts.
Deploy behavior depends on the service configuration. Zero-downtime deploys require enough running containers for Aptible to replace them without taking the whole service offline. A service configured with only one container is not highly available, and a service with a Persistent Disk attached canโt deploy with zero downtime.
If a deploy fails, Aptible can automatically restore the app to its last known good state. Aptible also supports two rollback paths:
Automatic rollbacks: Aptible rolls back when a deploy fails or when infrastructure failure requires restoring the last known good state.
Instant rollbacks: You can manually redeploy a previous successful image with no rebuild and no CI re-run, which is typically faster than a normal deploy.
Rollbacks revert code and configuration, not data: they wonโt undo a migration or restore deleted rows.
Services scale horizontally and vertically with app scaling. Apps at two or more containers are distributed across availability zones automatically as part of Aptibleโs operations model. Horizontal scaling goes to 32 containers from the dashboard and up to 128 through the CLI or Terraform.
Can I connect to external AWS resources like S3 or an existing VPC?
Yes. On dedicated stacks, Aptible supports network integrations such as VPC peering and site-to-site VPN for connecting to AWS resources or other private infrastructure. You can peer to an AWS VPC you own or to another of your own dedicated stacks. For latency and DNS, request an Aptible stack in the same region as your VPC.
A pattern we often see is customers hosting regulated apps and databases on Aptible, with S3, analytics, or AI vendors alongside. Any external service handling regulated data needs its own compliance review and contracts. Availability of dedicated stacks and related features depends on your plan.
What parts of application security stay my responsibility?
Aptible handles the infrastructure and platform controls. Your team owns application-layer security: authentication, authorization, secure coding, dependency management, secrets usage, PHI handling in code, application logging, and incident response for your own app.
