We had an App but nowhere to run it.

When we started working on Hostly, the original motivation was not that we thought the world desperately needed another hosting platform. We already had applications, services and background processes that worked perfectly well, usually packaged as Docker images, and what we wanted was a straightforward way to run them without redesigning parts of the application around the assumptions of the hosting provider.

There are plenty of very capable platforms available today. Vercel, Render and Railway have all made deploying software considerably easier than maintaining raw servers or Kubernetes clusters yourself, but when we evaluated them, we kept running into the same problem: we already had an architecture, and we did not particularly want the hosting platform to redefine it.

We just wanted to deploy what we already had

Vercel was an obvious initial option. It is extremely good at modern web applications and function-based workloads, but our applications were generally built around a simpler assumption: a process starts and keeps running until we stop it.

Vercel now supports Docker-based deployments as well, but those containers still run within Vercel's Function and Fluid Compute model. That works very well for applications designed around request-driven execution and automatic scaling, but it was not the model we were looking for.

Render came much closer. It supports normal Docker images and long-running processes, but also distinguishes between Web Services, Private Services, Background Workers, Cron Jobs and other workload types.

Those abstractions are useful, but they raised a question for us: why does the hosting provider need to know whether our container is a web server, a worker, or both? From our perspective, the application already knows what it is supposed to do.

Railway is probably the closest match to our own philosophy. It supports long-running containers, has a simple deployment model and hides most of the underlying infrastructure. The differences are therefore less technical and more about product direction: Railway is becoming a broad developer platform, while we wanted Hostly to remain narrower and, importantly for us, European.

Eventually the conclusion was simple enough: we built the platform we wanted to use ourselves.

The Docker image is the interface

The central idea behind Hostly is that the Docker image should already contain most of what the platform needs to know.

Your application has been built, its dependencies are defined and the image already knows how to start. Hostly therefore tries not to introduce unnecessary distinctions between different kinds of workloads.

A container may expose an HTTP port, consume queue messages, maintain WebSocket connections or run background processes. As far as we are concerned, those are implementation details of the application.

This also means that an application deployed on Hostly remains an ordinary containerised application. The same image should still be usable on a VM, Docker Compose, Kubernetes or another container platform.

This is not meant as a feature scorecard. Hostly deliberately does fewer things than some of these platforms; the important part for us is keeping the deployment model small and understandable.

Pricing should be just as understandable

We approached pricing with the same philosophy.

Cloud pricing can quickly become a combination of CPU, memory, invocations, function duration, build minutes, requests, bandwidth and various platform-specific resources. Every individual metric may make sense, while the resulting bill can still be surprisingly difficult to predict.

Hostly uses four usage metrics.

That's it.

The same pricing model applies whether a container is serving HTTP requests, processing background jobs or waiting for work. We want customers to understand roughly what an application will cost without first having to understand how our platform is implemented.

A running process should normally keep running

One of the clearer differences between Hostly and function-oriented platforms is the lifecycle of an application.

If you deploy a container and configure one running instance, our assumption is that you want that instance to remain running. Long-lived connections, queue consumers and background processes are therefore normal workloads rather than special cases.

Serverless platforms make a different trade-off, and for many applications that trade-off is excellent. Automatic scaling and scale-to-zero can be extremely efficient.

We simply found that many applications were already designed around persistent processes, and changing them purely to match the hosting environment would create more complexity than it removed.

European by default

There was also a non-technical requirement that mattered to us.

Vercel, Render and Railway all provide ways to run workloads in Europe, but they are still US companies. For us, there is a meaningful distinction between selecting a European region from an American provider and using a provider that is itself built and operated from Europe.

Hostly is a German company, and that is part of the product rather than simply another region in a dropdown.

It will not matter to every customer, but for European companies that care about where their infrastructure providers are based, we think the distinction is relevant.

We are deliberately keeping the problem small

Developer platforms tend to expand over time. Hosting becomes databases, queues, analytics, observability, workflows, AI infrastructure and eventually an entire ecosystem that developers have to learn.

There is nothing inherently wrong with that, but it is not what we are currently trying to build.

Our problem is much narrower:

You already have an application. You already have a Docker image. You need somewhere reliable and understandable to run it.

That is what we want Hostly to be good at.

Try it with something you already have

Of course, this is our own blog, so there is only so far we can go in convincing you that our approach is the better one.

The more useful test is to take an application you already have, deploy the same Docker image you would use anywhere else and see how little you have to change.

That is the experience we originally wanted for ourselves.

Our Free tier is... Free! Give it a try!

Deploy your first container