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.
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.
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:
aero deploycommand 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.
This flow provides some key advantages:
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
--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|
|Custom domain CNAME||
|Custom domain apex||
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:
If you are going to be using many stages we recommend the wildcard approach since it’s a one time setup.
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
plugins: - name: password-protect stages: [test] options: password: $SITE_PASSWORD
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
# 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.
You can configure email or Slack alerts when each deployment completes using a block of YAML in your
deploy: alerts: default: email: to: [userA@company.com, userB@company.com] slack: username: 'Website Update' webhookUrl: https://hooks.slack.com/services/xxx/xxx/xxxx ---
See the deploy configuration docs for full details.
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.