A new system status site

Sebastian Kippe ·

About two years ago we first launched our system status dashboard, keeping you up-to-date with the live status of all our infrastructure components.

As an uptime company – hosting both your client-side apps and static websites, as well as people’s precious personal data – we kept an excellent track record of keeping your things online and speedy since day one. But sometimes things just naturally go awry.

DDoS attacks on servers or whole networks, degraded hardware performance, and other problematic situations arise. And when they do, it’s important to us that you’re in the loop about what’s happening exactly.

In order to fulfill that goal even better from now on, we just launched a completely new system status site:


Our new site is based on Cachet, an excellent open source status page system. Compared to our old site, it brings some very useful improvements:

  • Status types are clearer and more exact. They now include “performance issues” (the most common one in day-to-day operations) and “partial outage”, apart from the less common “major outage”.
  • Incidents aren’t tied to one service/component necessarily anymore. An attack on our whole network e.g. will be a single incident with a single update stream (while retaining correct status per service).
  • Better status types for incident updates, ranging from “investigating” to “solved”
  • First-class support for scheduled maintenance announcements and statuses
  • A single RSS (or ATOM) feed to subscribe to instead of one per service

There are even some additional features we’re not using yet, but which we will set up in the near future. Namely email subscriptions, as well as displaying key metrics on the dashboard (like e.g. mean response time).

As was the case before, the status site is hosted outside of our core infrastructure, so that the likelihood of it being slow or unavailable when it matters most is extremely small.

Let us know if you like the new site, and be sure to check out Cachet in case you need something similar for your own organization or project!

P.S. I just realized that we launched this just in time for System Administrator Appreciation Day 2015. So, happy SysAdmin Day to our master of infrastructure, @gregkare, who’s been doing an amazing job at 5apps and beyond! (He’s also very funny on Twitter; you should follow him.)

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 *.5apps.com 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 *.5apps.com 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.

Archive of all entries