Show HN: Mist – a lightweight, self-hosted PaaS(trymist.cloud)
trymist.cloud
Show HN: Mist – a lightweight, self-hosted PaaS
https://www.trymist.cloud/
9 comments
Dokku user for a decade here, congrats on shipping, love to see more self-hosted PaaS options like this.
Why are binaries checked into the bin/ directory in the repo?
Compared to Dokku, I like how your LE support is builtin instead of a plugin. Is your main www ingress server an nginx that gets externally configured (like Dokku) or are you using net/http or libcaddy directly?
Dokku has a history of trying to compete with Heroku buildpacks - as a non Heroku/non Ruby developer this never resonated with me and there are a lot of vestigal parts (e.g. .web.1) that i would just put in my own Dockerfile directly. So focusing solely on Dockerfiles i personally feel is a good move.
One issue i faced with Dokku is eventually the build process for my Dockerized app was too memory-intensive to run on the VPS. I switched to running docker build locally, sending the container via `docker export | ssh | docker import`, and having a single `FROM myapp` dockerfile in Dokku. This was not particularly ergonomic to set up. Is it possible you can improve the UX of client-side built containers, or will you focus solely on the GitOps deploy?
Why are binaries checked into the bin/ directory in the repo?
Compared to Dokku, I like how your LE support is builtin instead of a plugin. Is your main www ingress server an nginx that gets externally configured (like Dokku) or are you using net/http or libcaddy directly?
Dokku has a history of trying to compete with Heroku buildpacks - as a non Heroku/non Ruby developer this never resonated with me and there are a lot of vestigal parts (e.g. .web.1) that i would just put in my own Dockerfile directly. So focusing solely on Dockerfiles i personally feel is a good move.
One issue i faced with Dokku is eventually the build process for my Dockerized app was too memory-intensive to run on the VPS. I switched to running docker build locally, sending the container via `docker export | ssh | docker import`, and having a single `FROM myapp` dockerfile in Dokku. This was not particularly ergonomic to set up. Is it possible you can improve the UX of client-side built containers, or will you focus solely on the GitOps deploy?
Thank you so much for your feedback.
The binaries are for local testing for now, the actual binaries are built on the server/VPS on installation, we are planning to distribute single binaries in future.
The reverse proxy + TLS is Handled by traefik running in a docker container itself, we chose traefik because of the automatic docker label based dynamic routing, I hope we don't need to switch to something else anytime soon .
We have plans for remote/local builds using a small docker registry instance on the server/VPS to eliminate the need of any external registry
The binaries are for local testing for now, the actual binaries are built on the server/VPS on installation, we are planning to distribute single binaries in future.
The reverse proxy + TLS is Handled by traefik running in a docker container itself, we chose traefik because of the automatic docker label based dynamic routing, I hope we don't need to switch to something else anytime soon .
We have plans for remote/local builds using a small docker registry instance on the server/VPS to eliminate the need of any external registry
This looks cool. I see under the "current limitations" section that it only supports a single node. Are there plans to change that? I'd imagine that database instances which got started on a single node deployment would be hard to migrate to a multi-node setup later on if they weren't originally spun up in that configuration (though ofc not impossible, just tricky).
Hi,
I agree with you, since we started for a single node only, to migrate to multi node there will be some user input required, we are and will try to keep breaking changes to minimal, but once we start to support multi node in future, the user will need to do some work, we'll make sure that it's minimal by providing simple scripts and tools.
Thank you for your feedback <3.
I agree with you, since we started for a single node only, to migrate to multi node there will be some user input required, we are and will try to keep breaking changes to minimal, but once we start to support multi node in future, the user will need to do some work, we'll make sure that it's minimal by providing simple scripts and tools.
Thank you for your feedback <3.
Gratz on shipping! I've been eyeing Canine for my next Hetzner setup, but the database support on Mist is a nice feature.
Looks like I have some experiments to run soon.
Looks like I have some experiments to run soon.
Dokku = steep learning curve according to your comparison chart? As a longtime Heroku user, I’d have to disagree.
Hi, the steep learning curve we mentioned is because of the cli and commands, for a user like me who is relatively very new to all this, a web based UI seems easier than a cli, I may be completely wrong, but we put that accounting for beginners.
I would love to know if we are missing something.
is this a coolify alternative?
I won't say it's an alternative, because:
1. We are very new compared to coolify
2. Mist provides somewhat similar service but not aiming to replace anything, we mainly focus on being beginner friendly and lightweight.
It's for small team or solo developers right now, but we are planning to expand
It's for small team or solo developers right now, but we are planning to expand
We’re building Mist, a lightweight, self-hosted PaaS for running and managing applications on your own servers.
We started Mist because we wanted a middle ground between raw VPS management and heavy, all-in-one platforms. Existing PaaS solutions often felt too complex or resource-intensive for small servers, homelabs, and side projects. We wanted something that keeps the PaaS experience but stays simple and predictable.
Our goals with Mist are: - A simple PaaS to deploy and manage apps on your own infrastructure - HTTPS, routing, and app access handled automatically - Low resource usage so it runs well on small VPSes - Self-hosted and transparent, with minimal magic
Mist focuses on being an opinionated but lightweight layer on top of your server. It doesn’t try to hide everything behind abstractions, but it does aim to remove the repetitive operational work that comes with managing apps by hand.
Mist is still early, and this is where we really need help. We’re actively looking for:
- Users who want a simple self-hosted PaaS and can share real-world feedback
- Contributors who want to help shape the core features, architecture, and UX
Website: https://trymist.cloud
Repo: https://github.com/corecollectives/mist