Hyper.sh: a Fun Step Up From docker-compose

Docker is great for local development. Spin up a container, mount some code to it, hack away. It’s a natural step up to docker-compose to mix additional services into your app. The docker-compose.yml format is both powerful and approachable. Now you’ve got a nascent project or proof of concept doing something interesting on your laptop.

But now you want to show someone else. Who might not have the patience to install docker, pull your repo, run your yml, etc.. You need hosting.

Hyper.sh is a smart step up that gets you a hosted instance quickly. If you’ve already gotten to some fluency with docker-compose on the commandline, then you’re ready to use hyper.sh. Their CLI utility closely mirrors how you already work with docker-compose. The documentation is solid. The web interface is informative, but really secondary to their CLI.

I haven’t used Hyper.sh for a production site yet. But there are many uses for containerized hosting other than hosting a production app, and for those cases Kubernetes is often overkill. Why give yourself the barrier of learning Kubernetes just to expose a proof of concept or dev app to collaborators and test users? I think Hyper.sh fits well for those cases.

I also tried Docker Cloud (formerly tutum) for these purposes, and didn’t enjoy it. DC doesn’t provide hosting, so hooking up with a hosting provider adds another layer of administration. The web interface purports to do everything, but was often slow. The web-based terminal app sucks. Not a fan.

Some tips:

If you get weird quota errors, just go to the Account > Quota page and use the link to request higher quota. Seems like they’ll generally grant the increase without asking questions. If you fool around and don’t delete stopped containers and unused images, it’s easy to hit the initial quota.
Hyper.sh doesn’t have built-in DNS, so expect to add A records somewhere else, or just access via IPs.
Each container that needs to be accessed publicly needs an FIP (floating IP). Allocate and attach (typically via the ‘fip’ property in your yml).
Think about using named volumes for your app, and configure those in your yml. You can hyper compose down and hyper compose up and not worry about deleting your data - volumes are maintained, and reattached to the new containers.
If your container dies for some reason that seems inexplicable, it could be out of memory. Try increasing the container size with the ‘size’ property in your yml.
Make sure to hyper pull [image] before you hyper compose up, if your image has been changed/rebuilt. Hyper won’t automatically check for the new version.

Cool things: they’re working on integration with log collection and a CD pipeline that starts with auto-built images.