Just launched: Free and instant HTTPS for custom domains

Sebastian Kippe ·

Good news, everyone! As of this week, we’re offering free, automatic, instant HTTPS for your custom domains on 5apps Deploy!

There’s no need for any manual steps in the whole process. As soon as you add a custom domain and point it to our servers, your app will automatically receive a certificate upon the first time it is visited via that domain.

Certificates are issued by Let’s Encrypt, a free, automated, and open Certificate Authority (CA). They are renewed automatically every few weeks by our configuration management systems.

In short: lean back and rest assured that your apps are delivered securely by an always-up-to-date infrastructure without you having to lift a finger, ever! Read on for some more details on the benefits of HTTPS (specifically for client-side web apps), and how to upgrade your existing apps on Deploy.

Let’s encrypt the whole Web

The reasons for going HTTPS all the way by default are many:


The most obvious benefit is security and safety for your users. With a plain HTTP connection, it’s not possible for their browser or device to validate that your app’s JavaScript and other resources were actually delivered from the correct server. That leaves a wide-open space for man-in-the-middle attacks and stealing your user’s data. 1

Privacy & Censorship

Another problem with bad actors in the middle being able to read user connections in plain text is that it’s easy to log hostnames and URLs being requested. That makes it possible for ISPs (and in turn authoritarian governments) to both store detailed profiles of users’ browsing activity, as well as block specific content by its domain name or URL (without having to block everything hosted under the same IP address).


Deploy supports HTTP/2 for modern clients (and SPDY for older ones). However, browsers only enable HTTP/2 when TLS/HTTPS is used. That means in order to enjoy the significant performance benefits of multiplexing requests, your site needs to be delivered via HTTPS.2

Access to Web Platform APIs

With most of the Web community being in consensus about wanting to encrypt the whole Web using HTTPS for the above-mentioned reasons3, browser vendors recently began restricting access to certain Web APIs for sites on insecure origins in their browsers (e.g. Geolocation and getUserMedia in Chrome). Likewise, new APIs will require HTTPS from the start, if they are sensitive to users’ security or privacy. The best way to ensure the uninterrupted functionality of apps using these features is to upgrade them to HTTPS as soon as possible.

Upgrading your existing apps to HTTPS

  • Existing apps on Deploy without a custom domain (using yoursubdomain.5apps.com) have been HTTPS by default for over 3 years now. If you previously considered using a custom domain, but didn’t want to pay extra for a certificate, now you can set it up for free.

  • Apps with a custom domain, for which you subscribed to our previous HTTPS add-on service, have been switched to the new, free certificates. The paid add-on will automatically expire and you will not be charged for renewal.

  • If you were running an app with a custom domain but no SSL certificate on Deploy, we have set up all of your apps for HTTPS already. However, in case you are relying on Web Storage, calls to HTTP APIs, or unencrypted WebSocket endpoints, we disabled automatic redirects to the HTTPS version of your app. Please check your email, as we have notified you in case your app is among those.

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.

Part 2: AppCache, Web Storage, and upgrading to HTTPS origins

We’ll soon publish a follow-up post about how we dealt with updating your cached offline apps using AppCache from HTTP to HTTPS. It will also include information on how to deal with migrating Web Storage data between HTTP and HTTPS origins. Subscribe to this blog or follow us on Twitter if you’re interested.


  1. While it is possible to attack HTTPS connections as well, it requires a lot of effort and usually specific targeting of single users, whereas attacks on HTTP can be done on a large scale in addition to being easy to attempt for anyone.
  2. We saw up to 35% load time decrease over HTTP 1.1 for apps delivered over SPDY and HTTP/2. Especially mobile clients with high-latency connections benefit considerably, when they can use a single TCP connection to load all resources.
  3. Also see the W3C Secure Contexts spec draft

Introducing service integrations

Sebastian Kippe ·

Good news, everyone! We just launched a new feature that lets you integrate Deploy with other services on the Internet. You can find it in the settings menu of your app panels:

We’re starting out with a few popular services, most of which we’re using for our own apps. Those are:

  • Slack and Grove.io for group chat
  • Sentry for exception/release tracking
  • Ghost Inspector for automated UI testing
  • A generic webhook for your own custom workflows and integrations

However, these are just a start. Use the link beneath the services list in order to tell us, which services you’d like to see next! We’re already looking forward to your requests.

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.

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!

Archive of all entries