Looking for our Bitbucket add-on?Click here to read about recent Aerobatic changes.


Aerobatic is a specialized platform for efficient delivery of static webpages and website assets. We take care of the configuration details for you that provide the best balance of performance and maintainability. Stop fiddling with CDNs and web server configs and focus on coding great front-end experiences.


Aerobatic utilizes a multi-layered global CDN so no matter where in the world your website visitors come from, the request is routed to the lowest latency servers. Website requests are initially routed to the optimal AWS CloudFront edge node (located throughout the world). Many assets such as images, JavaScripts, stylesheets, etc. are delivered directly from CloudFront. Your webpage requests are passed along to the lowest latency Aerobatic origin server (currently Oregon or Frankfurt, Germany with plans to expand to other regions). All resources are served with optimal caching headers by default.


All Aerobatic sites are served exclusively via SSL. All http:// requests are 301 redirected at the CDN edge to the https:// equivalent. Custom domains (included in Pro Plan) include a wildcard auto-renewing SSL certificate — set it once and never worry about certs again.

For additional security you can declare the http-headers plugin in your aerobatic.yml to append OWASP recommended headers to your HTTP responses.


Deployments are performed with the aero deploy CLI command which you can run locally from your desktop, or from within a CI build. Here’s the basic sequence of steps that comprise the deployment process:

  1. When the aero deploy command is run, the CLI generates a tarball with the contents of the local deploy directory. If your static site output is generated by a build step, either a static site generator or a build tool such as webpack or gulp, then it should run first.
  2. Your tarball is uploaded to an S3 staging bucket.
  3. A Lambda function is triggered which downloads the tarball, extracts it locally, performs optimizations, and writes the output to an S3 folder named after the unique version id.
  4. The contents of the S3 folder are replicated to each AWS region where Aerobatic operates origin servers (currently Oregon and Frankfurt, Germany).
  5. Once the version assets have been successfully replicated, the website metadata is updated indicating this new version should be served starting with the next incoming request.

This flow provides some key advantages:

  • You never have to worry about stale assets continuing to be served after a new version is deployed. As soon as the deployment is complete, everyone gets the latest and greatest, guaranteed.
  • Because previous versions are not overwritten, rollbacks are trivial - just a quick change in the control panel to point back to the previous version.
  • Geo load-balancing to the nearest AWS region means that your website visitors get a snappy downloads no matter where they are in the world.

Deploy stages

Aerobatic makes it super easy to deploy to different “stages”. A stage is simply an instance of the site available at a dedicated URL. This is a great way to manage testing and previews of new versions. By default the aero deploy command deploys to the “production” stage which is your main URL. However you can specify the -s or --stage argument to deploy to a different stage. For example:

[$] aero deploy --stage test

This will make the deployed site available at unique URL. The form of the URL depends on whether there is a custom domain and if the production site is using a CNAME or the apex.

URL style Production url “test” stage URL
Free plan https://site-name.aerobatic.io https://site-name--test.aerobatic.io
Custom domain CNAME https://www.customdomain.com https://www--test.customdomain.com
Custom domain apex https://customdomain.com https://test.customdomain.com

In the table above the stage name “test” could be anything you like, “preview”, “develop”, “etc”.

TIP When deploying to non-production stages with custom domains, you’ll need to configure DNS in one of two ways:

  1. Wildcard CNAME that covers *.yourdomain.net
  2. CNAME for each stage, i.e. test, preview, etc.

If you are going to be using many stages we recommend the wildcard approach since it’s a one time setup.

Password protection

You may wish to lock down these non-production instances of your site so only authorized visitors can access. This is easy to do with the password-protect plugin. The declaration below in your aerobatic.yml file will enforce password protection, but only in the test stage:

  - name: password-protect
    stages: [test]
      password: $SITE_PASSWORD

Continuous deployment

Deploy stages are particularly powerful in conjunction with a CI service. Your build script can automatically deploy git branches to correspondingly named stage. Here’s how that could be accomplished with Travis CI in the .travis.yml file:

# Your site's normal build steps here
npm install aerobatic-cli -g

# Deploy to a stage with the same name as the branch
aero deploy --stage $TRAVIS_BRANCH

# Or even use pull requests!
aero deploy --stage pr-$TRAVIS-PULL-REQUEST

TIP: any characters other than letters, numbers, dashes, or underscores in the stage argument will be converted to a dash “-” to ensure URL friendliness. So feature/new-nav will be feature-new-nav in the stage URL.

This technique works with any CI service that provides similar environment variables (and most all do). You can read more about setting up CI in the Continuous Deployment article.

Web logs

You can follow your web logs in near real-time using the either the aero logs command or in the web control panel. In addition to the usual web log fields such as URL, method, response code, etc. we also include the physical location of the end user by geo-location of their IP address.