Introducing SSL for custom domains

Sebastian Kippe ·


Good news, everyone! We’re finally launching one of the most requested features of 5apps Deploy: SSL for custom domains. It’s available immediately on all plans, including the free tier.

How it works

  1. You can order SSL for custom domains for the duration of either 1 or 2 years. We’ll send you a reminder when it’s time to renew, of course.
  2. The SSL certificate purchase, setup, and maintenance is fully managed by us. We’ll even regenerate and exchange your certificates on Heartbleed-type security events. You just order, and we’ll take care of the rest.
  3. For your own domain you’ll get the same excellent SSL setup that we’re using for all 5apps sites and services, as well as for the free * subdomains that you get with every app. Check out this example on SSL Labs for all details.
  4. The SSL setup is not attached to a specific app. You can switch domains on apps as much as you want, and if there’s a certificate available it’ll automatically be used with the app that’s using that domain.

Orders usually take less than 24 hours to complete. In the case of subdomains, you’ll need to add a new CNAME record in order to validate your domain first.


Apart from the obvious benefits of vastly increased security and privacy for your users, there’s one advantage you might not know about yet:

5apps Deploy supports the SPDY protocol, making your apps and sites load much faster on high-latency connections, like e.g. on mobile networks. But as SPDY actually requires SSL in order to work, it is only available on either * subdomains or custom domains with SSL enabled.

That means just by enabling SSL, you might be able to give your users significant load time improvements, especially on mobile devices and when you include a lot of separate resources.

Where to order

First, you need to set up your custom domain on an app. As soon as you’ve done that, you’ll see links for enabling SSL for that domain right under the custom domain field in your app settings panel:


You can also see an overview of all your custom domains as well as their SSL status on your developer account page.


In order to be able to use multiple SSL certificates on one IP address, we’re using Server Name Indication (SNI). This protocol has been around for a while, so it is supported by all modern browsers and operating systems. However, it’s not supported by Internet Explorer and Safari on Windows XP, as well as the stock browser on Android 2.x. In those cases we’re automatically downgrading to HTTP, so that your users aren’t confronted with invalid-certificate warnings.

Questions? Feedback?

As always, we’d love to hear your feedback and answer any questions you might have! Use the comments below, shoot us a tweet, drop us an email, or visit our support site.

Just launched: Improved usage limits and new pricing for 5apps Deploy

Sebastian Kippe ·

Good news, everyone! We just launched new subscription pricing and higher usage limits for 5apps Deploy, effective immediately for all users. We’re also giving you more insight into your apps’ traffic via charts and numbers on the app overview and dashboards.

When we introduced Deploy, it was the very first service of its kind, and in regards to many features we offer, it still is. Since Deploy’s beta launch over two years ago, we’ve learned a lot about the ins and outs of hosting client-side JavaScript apps and static sites, and this change reflects some of those learnings.

What changed?

  1. Usage is now limited by transfer volume instead of HTTP requests.
  2. The pricing structure of all paid subscription plans has been adjusted.


Over time, we’ve seen that our initial idea of limiting usage by HTTP requests partly fulfilled its goal of getting people to use AppCache in order make apps available offline. However, people love to host static sites on Deploy as well and AppCache doesn’t make sense for those. More importantly though, it was never quite easy or intuitive to comprehend request numbers as a measure, let alone estimate future usage based on what happens when you reload your apps a lot during development periods.

Ultimately, the old pricing just didn’t reflect the true cost of hosting high-traffic apps and sites. Let’s take ToS;DR – one of the most popular sites on Deploy – as an example. As ToS;DR is using the platform as fast and reliable hosting for their JSON API as well, they generate about 20 requests per second on average. Which means that on good days, they crossed the 2-million request limit of our most expensive subscription plan in a single day.

Now, as an open-source project, ToS;DR enjoys free hosting on Deploy, but if it were a proprietary app or site, the new limits would fit their transfer volume of about 30GB per month well within our medium-size plan now!

What didn’t change?

Although we did increase the price of our smallest plan, it happened because we didn’t change one important property of Deploy’s pricing: on paid plans, you can still set up an unlimited amount of apps, and all plans and usage limits are calculated per account instead of per app.

We also didn’t change the fact that you can set up custom domains on our free plans. Soon, you’ll even be able to purchase fully managed SSL encryption for your apps hosted with custom domains, independent of the plan you’re on.

Existing customers

As a thank you to all our early customers, we have upgraded your account limits, but not your subscription price! So, until you change your plan, you will be charged the same as when you signed up, but with significantly increased usage limits. Enjoy!

Bonus: more insight

There’s an additional improvement, which was made possible by how we log app usage now: starting today, we’re giving you insight into the traffic individual apps and sites generate, via charts and numbers on your apps overview and the app dashboards. These stats include both transfer volume and number of HTTP requests:

Questions? Feedback?

If you have any questions or feedback about our new pricing and usage limits, you can write a comment below, use our support site, or mention us on Twitter. We’d love to hear what you think!

Reset the Net – Adding HSTS and robust Perfect Forward Secrecy to all of our infrastructure

Sebastian Kippe ·


Today is the day we take back privacy on the Net! Not by asking for it, but by securing our software and infrastructure in a way that makes mass surveillance completely impossible.

5apps is joining the Reset the Net initiative today by making our services even more secure. We just rolled out updates to our live systems, adding HTTP Strict Transport Security as well as more robust Perfect Forward Secrecy to all 5apps sites and products, including your hosted apps on 5apps Deploy.

On the Qualys SSL Labs test suite, this takes our servers from an A- to an A+ rating. Check out the detailed report for one of my own apps on 5apps Deploy, in order to see exactly what we’re supporting.

Join us!

No matter if you’re an end user, software developer or server provider, we’d like to urge you to join Reset the Net today and pledge to take back your privacy and/or that of your users. We have the tools to fight back; now we just need as many of us as possible to actually use them.

Reset the Net!

Fetch as Google reveals how Googlebot successfully renders Ember.js apps

Sebastian Kippe ·

About a week ago, Google published a blog post titled Understanding web pages better, in which they confirm that Googlebot is indeed executing JavaScript these days, and that they’ve been gradually improving their indexing for it during the last few months.

Shortly after, the company added a new instrument to their Webmaster Tools panel, which shows you exactly what Googlebot sees, when it’s indexing a page. It is aptly named Fetch as Google, and out of curiosity I put it to the test with a simple Ember.js application today.

The test subject

I recently live-coded a small Ember application during a talk at Interactive Cologne, which fits nicely as a test dummy. Bitgogo is a rudimentary crowd-funding app, displaying the balance in a Bitcoin wallet as well as a target and the USD equivalent.

You can check out the code on GitHub; it’s as simple as it gets. There’s a Handlebars template, as well as some code fetching data from two REST APIs during startup (and polling from there on).

(Be sure to also check out our actual Indiegogo campaign for a movie about the East-African tech scene, that we want to create out of the 30+ hours of material we have from a trip through four African countries last fall.)

Fetch as Google in action

And so, without further ado, here’s what Googlebot sees according to Fetch as Google:



There you have it: Googlebot successfully rendered the Ember.js application, including the asynchronous fetching and subsequent rendering of the data!

Now, for less advanced search engines, you might still want to pre-render pages on the server, but given that the competition will likely catch up in the near future, it looks to me like rendering Web app content completely on the client-side will not be an SEO problem for too much longer.

Deploying static apps with grunt-build-control and 5apps Deploy

Sebastian Kippe ·

When using a local build toolchain to develop complex HTML5 apps, deploying a build subdirectory of your app repo with Git can be rather painful. On our deployments panel we suggest using git subtree for deploying build folders, but that’s really more of a hack and can lead to some problems, especially when working in team.

Fortunately, for users of Grunt there is a nice and easy solution for this problem now: the grunt-build-control task.

It makes it both easy to push subdirectories of a Git repository to a Git-based hosting service, like e.g. GitHub Pages and 5apps Deploy, as well as configure multiple deployment endpoints and even map different build folders and branches to those.

Getting started

First, make sure you’re using Grunt > 0.4.0 and Git > 1.8.

If you want to have a development and a production endpoint on 5apps Deploy, just create 2 different apps and name them accordingly. This is very useful in general, because it enables you to set deployment options according to the environment (e.g. don’t generate an appcache manifest for the development app).

Step 1: Make sure your build subdirectory is ignored by Git. If your build directory is called dist, your .gitignore should contain a line like this:


Step 2: Add grunt-build-control to your project:

npm install grunt-build-control --save-dev

Step 3: Load the plugin in your Gruntfile:


Step 4: Configure the task by adding its options to the Gruntfile (or wherever you keep Grunt task options):


  // Various Grunt tasks...

  buildcontrol: {
    options: {
      dir: 'dist',
      commit: true,
      push: true,
      message: 'Built %sourceName% from commit %sourceCommit% on branch %sourceBranch%'
    development: {
      options: {
        remote: '',
        branch: 'master'
    production: {
      options: {
        remote: '',
        branch: 'master',
        tag: pkg.version
    local: {
      options: {
        remote: '../',
        branch: 'build'

That’s it! Have a look at the project’s README for a list of all options and what they do.

Deploying your app

Now you can build and deploy your app like so:

grunt dist
grunt buildcontrol:development

Making it even more convenient

Right now we have to run these 2 commands all the time, and with no default for the endpoint (e.g. use development, unless we explicitly say it should go to production). So let’s create a little bash script that makes it even easier. Put this in a plain text file named deploy:


grunt dist

if [ $1 ]; then
grunt buildcontrol:$1
grunt buildcontrol:development

Then, use this command to make the file executable:

chmod +x deploy

Now, when you want to build and deploy to development, you can just run:


And when you want to build and deploy to production (or any explicit endpoint for that matter), it’s a simple:

./deploy production


Bonus for Ember App Kit users

If you want to add grunt-build-control to an Ember App Kit project, here’s a commit where I did just that in one of my apps.

Happy deploying!

If you have any questions or feedback, write a comment below or shoot us a tweet!

Archive of all entries