Scheduled maintenance on Tuesday, July 17

Sebastian Kippe ·

Please note: originally, this announcement was for Wednesday, July 11. However, we hit an unexpected roadblock during the initial migration and had to move the date.

As already announced on our system status site, We will be moving most of 5apps’ services to a new datacenter next Tuesday afternoon at 12:00 GMT. The planned impact will be as follows:


We will be putting the Web UI in maintenance mode for a planned maximum of 3 hours. There will be no downtime for hosted apps.

If you are using a custom domain, and it is routed to 5apps Deploy using a DNS A record with our current IP address, you will receive an email containing the new IP address sometime soon. However, we will be routing all traffic to the old IP to the new datacenter for a while, so you do not have to sweat anything. Just follow the instructions in the email at a time of your choosing.


The 5apps Storage Web UI will be put in maintenance mode for a maximum of 3 hours. This means you will not be able to authorize new apps, or revoke authorizations during that time. Your storage account itself will be put into read-only mode for a short amount of time within the maintenance window, so you can still read data, but not write any new data to it. Most remoteStorage-enabled apps will just keep working normally, and sync any data you changed during the window as soon as the account is writable again. Some apps will show an offline indicator/status.

Managed Storage

Storage accounts will behave exactly like outlined above. Creating and deleting tokens will be possible under a new subdomain/URL, when is put into maintenance mode. You will be contacted by our team, who will also answer any questions you might have, and help in any way they can.

Just launched: Instant deployment rollbacks

Sebastian Kippe ·

We’ve all been there before: you just deployed an update of your app to thousands of users, but then you realize something is wrong. Perhaps exception notifications start piling up, or you even see an outright blank page due to some nasty bug. In any case, finding the cause, fixing it, and deploying a new version, is oftentimes not a good option in emergency situations.

So we just launched a new feature for Deploy, which we had been testing and improving with some of our own apps for a while. You can now instantly rollback your deployments to earlier versions from your project’s deployments panel:

Screenshot of deployment rollbacks

Within seconds of pressing that button, your app or site will be delivered in exactly the state it was after that specific deployment.

How does it work?

The buttons are fairly self-explanatory, but here’s what happens behind the scenes: We’ll keep the last 5 builds of your app in our storage backend, where assets are delivered from.

The build number of the active version of your app is then stored in our Redis cache, which our load balancers also use for determining if your app has History API enabled for example (i.e. direct all URLs to index.html).

When you rollback or forward your project to a different version, we just switch the version key in that cache, and the load balancers then immediately start delivering the assets for that specific version.


If you’re using AppCache (e.g. via our automatic AppCache manifest generation), then depending on how much time passed between the deployment and your rolling it back, users might have cached the latest version of your app, of course.

In that case, they’ll either have to wait until their next visit (default with AppCache), or you can always prompt them to reload, whenever a new version has been downloaded and cached in the background. For the latter, we also offer an automated deployment strategy, which you can enable by just flipping a switch on your app’s deployment settings page.


If you have any questions or feedback, just leave a comment below. You can also ping us on Twitter, drop us an email, or visit our support site.

New service integration: Deploy notifications for Mattermost

Sebastian Kippe ·

It’s no secret that we care a lot about open source software at 5apps. So we’re excited to announce that you can now receive notifications from 5apps Deploy in your Mattermost chatrooms:

Screenshot of Mattermost chatroom integration

You can set it up from the “Services” settings page in your app panel, where you could already connect Slack, Sentry, Ghost Inspector and other services:

Screenshot of 5apps Deploy services settings

We’ll be adding more services over time, and we happily accept your suggestions for new services to integrate. If you’d like to request a new one, you can do that straight from the settings page, using the link under the services selection.

Enjoy! is shutting down

Sebastian Kippe ·

Unfortunately, is finally being shut down this Thursday. We were big fans of both the BrowserID protocol and Mozilla’s Persona service. And so were our users. Around 30% of new accounts were created using Persona, until Mozilla announced its shutdown in January this year.

Personally, I still think it was a great idea, which unfortunately wasn’t met with enough enthusiasm on the side of the big email providers. But no point in wallowing in the past, so here’s what you can do, in case you signed up on via Persona and haven’t enabled another login option yet.

Connect GitHub, Bitbucket, or

In addition to our existing GitHub login, we also just added support for Bitbucket and All of these options will also import your SSH public keys to 5apps Deploy, in case you’re signed up for it.

You can enable these options on the Connections page in your account settings, after logging in with Persona (before Thursday) or via username/password.

Enable username/password login

In order to enable password login, just go to your account settings and enter a new password. In case you can’t log in via any other method anymore, just request a password reset, and we’ll send you an email with a reset link right away.


If you have any questions or feedback, just leave a comment below. You can also ping us on Twitter, drop us an email, or visit our support site.

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 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

Archive of all entries