Managed HTTPS Endpoints

Thomas Orozco on August 4, 2016

Earlier this week, we released Managed HTTPS Endpoints. These endpoints have a few key benefits:

  1. Your SSL/TLS certificate is free (!)
  2. Aptible handles generating the initial certificate
  3. Aptible handles renewing the certificate

All you need to get started with a Managed HTTPS Endpoint is a domain name! No more ops headaches trying to generate CSRs, keep private keys and certs straight, or deal with inconveniently-timed renewals.

Under the hood, Managed HTTPS uses Let’s Encrypt to automatically provision certificates for you. Aptible customers requested this feature, and we are proud to contribute to the global movement towards 100% HTTPS.

How it works

'Create a New Endpoint' view

Setting up a Managed HTTPS Endpoint is a 3-step process:

  1. Add an Endpoint to your app, and choose Managed HTTPS as the endpoint type. You will need to provide the domain name you intend to use with your app (e.g. Aptible will use that name to provision a certificate via Let’s Encrypt.

  2. When you create the endpoint, Aptible will provide you with an endpoint address. Use your DNS provider to create a CNAME from your domain ( to this endpoint address (something like

  3. Back in the Aptible Dashboard, confirm that you created the CNAME. Aptible will automatically provision your certificate, and you’re in business!

Note that between steps 2 and 3, your app won’t be available because you need to set up the CNAME before Aptible can provision the certificate. This isn’t ideal if you are migrating an app from somewhere else. Fortunately, you can just provide a transitional certificate that Aptible will use until your new Let’s Encrypt certificate is available. If you need to add a new certificate for this, just select the "Certificates" tab under your main environment view.

Once your endpoint is up and running done, we recommend you review our instructions for customizing SSL, in order to redirect end-users to HTTPS and disable the use of weaker cipher suites, which will earn the much-coveted A+ grade on Qualys’ SSL Test!

Qualys SSL Test results

Why use Managed HTTPS?

Above all else, Managed HTTPS brings you simplicity and peace of mind:

  • Setup is greatly simplified: all you need is a domain name. No need to generate your own certificate signing request, deal with a CA, or upload your certificate and key to Aptible.
  • Maintenance is essentially eliminated: you won’t need to remember to renew a certificate ever again.
  • Oh, and did we mention it’s free?

Enjoy! As usual, let us know if you have any feedback.

Read more

Deploy From Private Docker Registries

Blake Pettersson on July 31, 2016

Aptible customers have always been able to streamline deployment by building from base images hosted in public Docker registries. For example, the Aptible Ruby on Rails Quickstart uses FROM, eliminating the need to install Ruby during each Aptible build.

Many customers would like to do even more work outside their Aptible build, including prebuilding code that should be kept private. In those cases, pulling a base image from a public Docker registry is not feasible, so today we are happy to announce that you can now deploy Aptible apps from private images hosted on Docker Hub,, and other private registries! This feature is supported for all v2 stacks.

How does it work?

To start from scratch, first create an app on Aptible. You will still need to use git, since we will still push a repo with a single Procfile file, used to define the app's services and their commands. If your entire app is prebuilt in the image, you do not need a Dockerfile.

Next, use the Aptible CLI's aptible config:set command to set a few environment variables:

  • APTIBLE_DOCKER_IMAGE - The name of the image to pull, in the format registry_host/repo/image_name:tag. Repo and image name are required. Tag is optional and will default to latest. If you are not using Docker Hub (if for example you're using then the registry host name is also required.
  • APTIBLE_PRIVATE_REGISTRY_HOST - The private registry host to pull from. Required when pulling from a private registry. Defaults to
  • APTIBLE_PRIVATE_REGISTRY_USERNAME - The username to use when pulling the image. Required when pulling from a private registry.
  • APTIBLE_PRIVATE_REGISTRY_PASSWORD - The password of the registry to pull from. Required when pulling from a private registry.
  • APTIBLE_PRIVATE_REGISTRY_EMAIL - The e-mail to use when pulling. Optional. Defaults to .

Note that you can omit a Dockerfile and only set APTIBLE_DOCKER_IMAGE to initiate a deploy from a public Docker registry image.


To illustrate the steps above, assume we have a basic Ruby on Rails app image prebuilt and hosted in a private registry:

$ mkdir example-docker-app
$ cd example-docker-app && git init .
$ aptible apps:create example-docker-app --environment my-env
> App example-docker-app created!
> Git remote:
$ echo "web: bundle exec rails s" > Procfile
$ git add Procfile && commit -m "test docker pull"
$ git remote add aptible
$ git push aptible master

In this example, because you set APTIBLE_DOCKER_IMAGE, when you git push the platform will pull and run the image specified using the provided credentials.

Note that if a Dockerfile is present, APTIBLE_DOCKER_IMAGE will override the Dockerfile and the Dockerfile will be ignored.

Extending a Private Image

You may want to still build an app from scratch upon deploy, but would like to standardize or harden a private base image. In this case, your Aptible app will still need a Dockerfile commited to version control, but the Dockerfile's FROM directive can reference a private image. Be sure to specify your registry credentials with the variables above, but be sure to omit APTIBLE_DOCKER_IMAGE (since otherwise the Dockerfile will be ignored).

As usual, we would love to hear your feedback! If you have any questions or comments, please let us know!

Read more

On-Demand Database Backups

Thomas Orozco on June 21, 2016

Contingency planning and disaster recovery are critical parts of any developer’s HIPAA compliance program. The Aptible platform automates many aspects of secure data management, including long-term retention, encryption at rest, taking automatic daily backups of your databases, and distributing those backups across geographically separate regions. These benefits require no setup and no maintenance on your part: Aptible simply takes care of them.

That said, recovering a database from a backup has required a support request. While we take pride in providing timely and effective support, it’s nice to be able to do things at your own pace, without the need to wait on someone else.

That’s why we’re proud to announce that for all v2 stacks, you can view and restore backups directly in the Aptible dashboard and CLI! (For customers on v1 stacks, you can view, but not self-restore.)

How does it work?

In the dashboard, locate any database, then select the “Backups” tab. Find the backup you would like to restore from, and select the “Restore” action. From the CLI, first update to the newest version (gem update aptible-cli), then run aptible backup:list $HANDLE to view backups for a database, or aptible backup:restore $ID to restore a backup.

Restoring from a backup creates a new database - it never replaces or overwrites your existing database. You can use this feature to test your disaster recovery plans, test or review new database migrations before you run them against production, roll back to a prior backup, or simply review old data. When you are done using the restored database, you can deprovision it or promote it to be used by your apps.

But wait, there’s more!

Introducing On-Demand Backups

In addition to displaying automatic daily backups, you can now trigger a new backup on demand from the dashboard or CLI. In the dashboard, simply select the large green “Create New Backup” button. From the CLI, make sure you are running the latest version (gem update aptible-cli) then use aptible db:backup $HANDLE to trigger a new backup.

Now, before you do something scary with your database (like a big migration), you have an extra safety net. On-demand backups are easier than filing a support request and safer than using a tunnel to dump to a local environment, because you will never have to remember to purge data from your machine.

We hope you find both of these features useful! That’s it for today. As usual, if you have questions or feedback about this feature, just get in touch.

Read more

2-Factor Authentication!

Thomas Orozco on May 19, 2016

We're happy to announce that two-factor authentication (2FA) is available for all users and account types in the Aptible dashboard and CLI! Multifactor authentication is a best practice that adds an additional layer of security on top of the normal username and password you use to verify your identity. You can enable it in your Aptible user settings.

How does it work?

Aptible 2-factor authentication implements the Time-based One-time Password (TOTP) algorithm specified in RFC 6238. We currently support the virtual token form factor - Google Authenticator is an excellent, free app you can use. We do not currently support SMS or hardware tokens.

When enabled, 2FA protects access to your Aptible account via the dashboard, CLI, and API. 2FA does not restrict Git pushes - these are still authenticated by your SSH key. In some cases, you may not push code with your own user credentials, for example if you deploy with a CI service such as Travis or Circle and perform all deploys via a robot user. If so, we encourage you to remove SSH keys from your Aptible user account.

What if I’m locked out?

When you enable 2FA, you get emergency backup codes, in case your device is lost, stolen, or temporarily unavailable. Keep these in a safe place. If you don't have your device and are unable to access a backup code, please contact us.

As usual, we'd love to hear your feedback! If you have any questions or comments, please let us know!

Read more

Aptible Logs: v2

Thomas Orozco on May 16, 2016

If you are on an Aptible "v2" stack, which automatically scales your app containers across AWS Availability Zones, you have probably noticed that the aptible logs CLI command has been deprecated. As an alternative, you’ve been able to use Log Drains to collect app logs.

A Log Drain’s ability to persist logs (not just stream them) makes it a robust option, however each drain requires some setup. aptible logs is built in to the Aptible CLI, requires no additional setup, and makes it easy to see what is happening in your app right now.

We’re happy to announce that aptible logs is available on Aptible v2 stacks!

How Can I Use It?

If you already have the Aptible CLI installed, then you don’t need to do anything: using aptible logs from the CLI works on all stacks as of today. There is a deprecation notice for aptible logs in older versions of the CLI - you can make it go away by updating the CLI.

If you don’t have the CLI installed, follow the installation instructions first.

Technical Details

aptible logs on v2 stacks is implemented as a Log Drain that doesn't drain: instead, it buffers logs received from log forwarders and allows clients to stream the buffer.

As a result, the first time you use aptible logs on a v2 stack, we’ll take a few minutes to automatically provision a special new "tail" Log Drain, if you don't already have one. Once you have a tail Log Drain, subsequent aptible logs calls are fast.

If you have any questions or feedback about this new feature, please let us know!

Read more

Introducing Container Metrics

Thomas Orozco on April 7, 2016

Aptible customers have been asking how they could view performance metrics such as RAM and CPU usage for their containers. We’re happy to announce that the wait is coming to an end!

Last week, we started rolling out the first iteration of our new Container Metrics feature. You can access them via the "View Metrics" buttons on an App's service list, or the "Metrics" tab for a Database. As an Aptible user, this lets you visualize performance metrics for your app and database containers directly from your dashboard. In turn, you can use this information to identify performance bottlenecks and make informed scaling decisions.

Metrics are available for apps and databases. In both cases, you can vizualize:

  • Memory usage, including a breakdown in terms of RSS vs. caches / buffers. We’ll soon be including your memory limits in the graph as well, so you can compare your actual usage to your memory allocation.

  • Load average, which reflects the overall activity of your container in terms of CPU and I/O.

Both of these metrics are "bog-standard" Linux metrics, meaning there is a ton of information about them on the Internet. That being said, you can also hover over the little "?" icon in the UI for a quick reminder:

image alt text

Using Container Metrics to Debug Performance

Let's work through an example of how you can use these charts to understand performance issues and make scaling decisions. In this example, we’re running pgbench against a Postgres database (initially provisioned on a 1GB container), and we’ll explore easy ways to get better performance out of it.

First, take a look at the graphs:

image alt text

  1. It looks like database traffic surged at 6:24 PM UTC, lasting until 6:44 PM UTC. That’s our pgbench run.

  2. Our container quickly consumed 100% of its 1 GB of available memory. Most of the memory was allocated for kernel page caches, which Linux uses to minimize expensive I/O requests.

  3. With a load average consistently over 20 (i.e. > 20 tasks blocked waiting on CPU or I/O), our database operations are going to be very delayed. If our app was experiencing slowdowns around the same time, our database would be a likely suspect.

Armed with that knowledge, what can we do? A high load average can be caused by a bottleneck in terms of I/O or CPU, or both. Detailed CPU and I/O metrics are coming soon. In the meantime, upgrading to a bigger container might help with both our problems:

  • Our CPU allocation would be bigger, which essentially means we’d run CPU tasks faster.

  • Our memory allocation would be bigger, which means more memory for caches and buffers, which means faster disk reads (disk writes on the other hand would probably not be faster, since it’s important that they actually hit the disk for durability, rather than sit in a buffer).

Using Container Metrics to Evaluate Scaling

After upgrading our container, let's run the benchmark again:

image alt text

Clearly, the kernel is making good use of that extra memory we allocated for the container!

This time around, the benchmark completed faster, finishing in 12 minutes instead of 20, and with a load average that hung around 10, not 20. If we had an app connecting to our database and running actual queries, we’d be experiencing shorter delays when hitting the database.

Now, there’s still room for improvement. In a real-world scenario, you’d have several options to explore next:

  • Throw even more resources at the problem, e.g., an 8GB container, or bigger. Perhaps more unexpectedly, using a larger database volume would probably help as well: Aptible stores data on AWS EBS volumes, and larger EBS volumes are allocated more I/O bandwidth.

  • Optimize the queries you’re making against your database. Using an APM tool like New Relic can help you find which ones are draining your performance the most.

  • Investigate database-level parameter tuning (e.g. work_mem on Postgres).

I hope this example gives you an idea of how you can use Container Metrics to keep tabs on your application and database performance, and make informed scaling decisions. If you have any feedback or questions regarding this new feature, please do get in touch with Aptible support!

Read more

No Flash, No Problem

Gib Reimschüssel on October 28, 2015

We addressed a small UX issue in our dashboard application this week. A
blog-post-worthy UX issue? Not really. Transparency in the process of how
we address issues however, can greatly benefit our customers and their
experience with our products.

Aptible is an application deployment platform built to automate HIPAA compliance
for web and mobile technology. We have a web-based
dashboard application
to aid customers in managing their organization, access controls, and ops.
It is built with EmberJS, an open source JavaScript
application framework.

Contributing to the EmberJS community motivated our decision to open source
the dashboard. Often available applications are small and optimized for
evaluating the framework quickly. Sharing our production application builds on
the many smaller examples and helps answer bigger questions around code
organization, utilizing components, and test coverage.

We use a copy-to-clipboard action throughout the app for
long strings that a user would likely need to paste in a terminal
(database connection strings, git commit references, links, etc.).

A user reported some confusion via one of our support channels when the
click-to-copy link reloaded their browser.
A github issue
was created and diagnosed the root of the problem. In browsers without Flash,
the component was not set up and a link with a common placeholder destination,
triggered the reload.

<a href="#">Copy</a>

Because the dashboard is open source, anyone with a free github account can
create, comment, and follow issues. A new open source tool,
clipboard.js, was noted as a
possible solution. It does not use Flash and offers a nice fall-back for
unsupported browsers to get targeted text on the clipboard. Note, the tool's
creator, zenorocha chimed in with a
+1 and a wink. Feel the open source github love!

The click-to-copy component used in the dashboard is part of our shared library,
also open source. After making changes to the component, we updated the
dashboard, and problem solved!

Why is this awesome?

  • Code change discussions are out in the open, tagged and timestamped.
  • Customers can submit or comment on issues directly.
  • The community can learn from and build on our open applications' structure.
  • Recruiting. Like what you see?

Check out
all of Aptible's open source repositories
or pick from the following highlights:
Aptible's public website.

Aptible's customer dashboard (aka Diesel). It allows users to manage organizations, access controls, and ops.

Command-line interface for Aptible services.

An alternative CLI for Amazon OpsWorks, focused on managing a large number of similarly provisioned stacks.

Aptible's support documentation.

Sample Docker files to get various versions of NodeJS running on Docker.

Example implementation of cron jobs on Docker/Aptible.

* To see the latest Dockerfile examples and Docker related repositories,
view all of Aptible's repositories and search
for Docker.

Read more

The Most Popular Databases in Digital Health

Sam Yount on October 27, 2015

This is the second in a series of blog posts exploring the state of the digital health landscape from a technical perspective. Our first post on popular languages has already proven to be one of our most read blog posts. If there are other analysis you would like to see on the state of digital health, please get in touch

One of the things we have noticed in working with a variety of digital health companies is that there is much more willingness to explore database technologies when architechting a new application. While developing in a new language typically takes a serious investment and will greatly slow initial progress, a different database variant may present lots of benefits with a minimal learning curve. As such, I expect we'll see some interesting trends emerge as we repeat this survey over the coming months and years.

For this survey, we examined the database layer for applications deployed on Aptible. The pupulation of databases is limited by what Aptible (and AWS) support. That said, we are very quick to add support for any database requested by users.

google.load("visualization", "1", {packages:["corechart"]});
function drawChart() {
var data = google.visualization.arrayToDataTable([
['Database', 'Percentage'],
['PostgreSQL', 45.4],
['Redis', 20.8],
['MongoDB', 12.3],
['MySQL', 12.0],
['CouchDB', 0.3],
['RethinkDB', 0.2]

var options = {
  colors: ['#dc3912', '#36c', '#f90', '#109618', '#909', '#0099c6'],
  height: 350,
  pieSliceText: 'label',
  tooltip: { text: 'percentage' }

var chart = new google.visualization.PieChart(document.getElementById('piechart'));
chart.draw(data, options);


As this is the first time we have collected this data, we can’t make any definitive claims about trends. However, DB-Engine is a great source for trends in database popularity. Their methodology, however is much squishier than our directly measured metrics.

DB-Engine October 2015 Ranking

3Microsoft SQL
7Microsoft Access

The most interesting difference in these lists is with Redis. The Aptible data is based on web and mobile applications while the DB-Engine list is based on a much broader variety of factors. So Redis may make more sense for the types of applications currently "hot" in the health tech world. It'll be interesting to see how the list changes and whether the Aptible list is a leading indicator of rapidly growing Redis popularity.

Read more

The Most Popular Languages in Digital Health

Sam Yount on October 6, 2015

This is the first in a series of blog posts exploring the state of the digital health landscape from a technical perspective.

Working exclusively with companies in digital health, we are regularly asked about technical trends. One common question is, "What types of languages and frameworks do you see the most?" As a deployment platform for nearly 100 (as of October 2015) digital health companies with over 550 deployed applications, we have some interesting data.

For this survey, we examined the primary language for apps deployed on Aptible. We have tried to only include primary production apps and exclude any helper or logging apps (e.g., the ELK logging stack is a popular utility to run on Aptible, but doesn’t tell us much about the main app.) Finally, of course, these data only represent apps deployed on Aptible, so ASP.NET-specific languages are not represented.

google.load("visualization", "1", {packages:["corechart"]});
function drawChart() {
var data = google.visualization.arrayToDataTable([
['Language', 'Percentage'],
['Ruby', 41.3],
['Node.js', 33.2],
['Python', 12.6],
['PHP', 8.1],
['Java', 3.5],
['Go', 1.3]

var options = {
  colors: ['#dc3912', '#36c', '#f90', '#109618', '#909', '#0099c6'],
  height: 350,
  pieSliceText: 'label',
  tooltip: { text: 'percentage' }

var chart = new google.visualization.PieChart(document.getElementById('piechart'));
chart.draw(data, options);


As this is the first time we have collected this data, we can’t make any definitive claims about trends. There are other sources of data for the general tech community, such as RedMonk's survey on popular programming languages and BuiltWith’s Framework Usage Statistics.

RedMonk Language Ranks


BuiltWith Top 10k - Frameworks

5Ruby on Rails Token
6Shockwave Flash Embed
7Ruby on Rails
9Adobe Dreamweaver
10Classic ASP
11Adobe ColdFusion
14Django CSRF
15Telerik Controls

Ruby and JavaScript dominate the Aptible sample, which makes sense because Aptible is used primarily to deploy web apps and mobile APIs. PHP is also popular, as it is on the open web. Java and PHP are used less frequently on Aptible than on the open web. To speculate, this may be because many Aptible apps were built recently, whereas top 10k sites may be older, with more legacy code.

Read more

Smoother Ember Upgrades

Chas Ballew on August 14, 2015

Ember 2.0 has been released! Major thanks to Robert (@rwjblue) and our good friend Matthew (@mixonic) for their blood, sweat, and tears.

How does a major open-source framework approach upgrades? Find out in Robert's talk at the Ember.js NYC meetup last month.

If you find this interesting, join us!

Read more