The cloud space is absurd, we've sat by for 2 decades while the likes of AWS define every aspect of deployment, auth, even containerisation.
Containerisation was supposed to mean host anywhere, literally redeploy a complex set of services and their connections on any cloud provider at the drop of a hat. That is what a f**ing shipping container is, you rock up to any port in the world and the same container is lifted by any crane onto any ship or truck.
Amazon, Google, Microsoft - these people have sold vendor lock-in to the very segment of tech society that should have been fighting it tooth and nail. 20 years ago you ftp'd some PHP files and it just worked, now you have to figure out 20 IAM profiles and shit your files across buckets because everything must be 1000000x scalable out of the box.
No joke I was building a static firebase site the other day and just wanted a simple way to password protect it (like http auth) for staging so my client could see it - of all the useless shit firebase tries to lock you into they can't even do something as simple as basic http auth without a shit show and spinning up a cloud run instance or something to check a static password.
Yes we 100% need fix hosting, everything should be portable, simple, generic.
I think a lot of programmers in the industry just follow trends, they don't really understand the benefits and drawbacks of the technology they are using.
I have coworkers who host personal projects for their own use and put them in docker, set up CI pipelines, host them on a cloud service, use an enterprise level database on the backend. One of my coworkers made a completely static portfolio website with a single page and used react.
I don't mean this in a judgemental way, people are free to use whatever they like. But it does sadden me that instead of seeing tools and processes as having certain benefits and certain overheads it's now just "this is the tool we use for everything", and therefore "everything now has this overhead". Where the overhead is performance, time, complexity.
I think vendors will do what vendors will do, and you can choose to buy into that or not. Containers fullfilled their promise. You can today host anything yourself easily, with a single command.
The problem comes when developers start building things without this in mind. I see simple site analytics apps in github, where the docker compose file is a web os services and the repo itself is full of init scripts and the sort. You have redis, mongo, an RDBMS container, an analytics db, kafka, all the kafka tooling like bookkeeper, then you have outsourced auth liek clerk or supabase (when the whole thing is not just some supabase chimera with edge functions and whatever else supabase is supposed to run outside your infra).
And the repo description is: simple, anonymous wesbite analytics.
The entire thing is more complex than the thin you want to do analytics for.
So you bring that into a cloud, and instead of a container, you are now advised, but both AWS and your HN peers that you need to replace each component with it's cloud version, such as elasticache, AKS, cognito, firebase, whatever.
All of these services as you set up, trap you into overprovisioning. Your DB needs to have 3 replicas or you have no guarantees, your auth needs an entire instance of something running somewhere or unicorns start dying.
By the time you come out for sunlight your bill could pay your rent. So you don't self host, you signup for google analytics.
Everytime I find a project on GitHub, the first thing that makes me close it immediately is whether it has a docker-compose.yaml and if it's a single, sane/dumb, low footprint deployment or a chimera.
So self hosting is alive and well, whether your app is easy to self host, and whether you know how to use just what you need from cloud vendors are different questions.
If you don't mind me asking a question to better understand your perspective: Are you old enough to have personally experienced and built self-hosted things before the advent of AWS, cloud hosted stuff, or is your text above (which I do not disagree with in any way) the point of view of a person who began working on this stuff in the "cloud-native" era, post-2012 or around then?
I'm thinking from the "20 years ago" it is the first one, so your experience is even more valuable for those younger persons reading it because you've seen how things were before the vendor-lock-in era began.
I ask because I've been seeing an increasing trend of people who've self-taught themselves Linux/BSD things, grew up in the cloud-native era, and have now become increasing dissatisfied with the "Do everything in one vendor cloud" operations model that they initially learned. Many are now going the opposite direction and deciding to self host their own projects at much lower cost and much less vendor lock-in.
I'm in my 40s, full disclosure I've never worked in devops 'officially' but have hosted many personal and commercial projects, worked as a developer and later product manager. I have run my own small businesses as well as working for various corps.
In defence of cloud I will say that back in mid 2000s I did have to buy and rack my own servers, this was a pain in the ass and I don't want to ever see and especially hear the inside of a datacenter again. I'll also say that a lot of things are much easier and safer today, the industry has developed a lot of process and tooling.
So the issue isn't necessarily "cloud" but how large cloud vendors have strategised in their own best interests to do vendor lock-in, especially on the lower end of startups that are obviously open to shipping now and paying later, and how we have all lapped that up because they do give generous free-tiers and they do solve some real problems.
Yeah, self-hosting is definitely having a come back. Lots of content creators who would have been evangelizing cloud solutions in the past have been instead going into the various self hosting rabbit holes. There is a bit of a pendulum swing. You now have access to so much information and tooling to host your own things, it’s pretty awesome compared to what we had before 2010.
Not sure how much impact that will have for companies, that will likely stay more niche. Companies will still want to delegate much of the effort to a cloud provider, but with pressure to have less lock-in
I've worked for a corp that spent good money to mirror their entire Salesforce setup internally on the basis that Salesforce was expensive, slow, and had all their customer data and could bring the entire business to its knees.
I've worked for another corp that spent insane amounts for a CMS that nobody understood and required a full time engineer on duty to "unlock" files for the content team - this company later built a simple CMS that just stored a title, body and image in a database because I shit you not: thats 90% of what they needed from a CMS and to do quick announcements/news in a mobile app would have taken weeks longer to develop if they had to integrate with the real CMS.
This was a few years ago before LLMs btw, so I can only imagine how crazy it is today
I remember driving to the datacenter to setup my own servers. I had a fractional T1 to my desk, it provided a blazing 640k (sometimes all the way up to an unfathomable 1MB!!1!) of bandwidth and only cost around $1,300 a month. Good times.
That gave way to hosting providers, like ServerBeach and Rackspace, where you paid them to setup the server hardware for you, saving the drive. You still had to deal with bandwidth, backup, redundancy, etc. Much easier than before but still a pretty big hassle.
Then the cloud happened. "Come to the cloud, where everything just magically happens for you," the salesperson said. So I went. And discovered that none of my scripts, tools or knowledge worked there, and had to completely start over from scratch. FOR EACH VENDOR. Gah.
The ONE thing I will grant cloud providers is that I can usually automate my way around their enshittification. They over-complicate things to an extreme where I do wonder if there is an actual savings or not, just based on the headaches their setups can consistently produce.
My take is that your needs pretty much determine which route is more/less painful. Sometimes you DO need the redundancy and uptime enough to tolerate the shenanigans of the vendor, and other times you just need your own machine to quietly get things done (without worrying about SLAs or client expectations).
The ultimate question you should be asking, and there is no right/wrong answer: For this particular effort, is it more valuable to you to learn how to do these things by hand, or is the infrastructure just a means to an end so you can do something specific?
Yeah agreed, there are pros and cons but ultimately we are exchanging control for convenience.
The idea of a hosting provider that manages all the boilerplate, security updates etc is not a bad thing. The idea of being able to spin up another node, have load balancing etc just work and you didn't even have to get out of bed - is also not a bad thing.
Where it becomes suspicious is when Amazon and Google both have their 'own' databases, which are just different enough to make it a pain. And yes I know I can spin up e.g. a Postgres instance on Google or AWS for not much money, but now I have a vendor-specific provisioning script. "Just use Terraform or Pulumi" - even when an LLM manages this web of corporate enterprise nonsense it's still unmanageable and everyone just ends up with a run book of prayers.
That's why, every time a discussion comes up about decoupling from the US tech and cloud offering, and how supposedly the whole world is captive and incapable without it, I'm like "well, certainly we should give it a serious try, because we might love a bit too much what we encounter down the road in terms of complexity and costs savings."
yea i also think it's weird that people who aren't doing work for organizations champion using aws/gcp/azure.
we've all been around computers for a hot minute, we've seen stuff that is exciting and fun and easy to use, and stuff that is not.
i occasionally do a bit of aws and azure deployments for work, everything is reduced to yaml hell, i think its the most over convoluted experience ever to do anything and opaque billing strategies, abstractions, it's just gross. its hard to be passionate about that stuff.
i kind of laugh when people at my org talk about colocation and elastic strategies for some podunk reporting app, like the bare minimum sla 99.9999999% uptime and runs in regions close to the data and weeks of planning to have like a stupid crud app that maybe five people. use. everything has to neatly fit into this one size fits all cloud strategy the infra/devops team came up with and they could've just run multiple apps off a server rack in the office it's literally an internal tool. or hell they could've just came up with a desktop app deployment strategy to company devices and not used any cloud services. feels so boring
feel like the field of "devops" just kinda threw their hands up got really weird this past decade, and like you said just kinda bought into the deployment strats aws/gcp/azure pulled out of their ass.
You can still ftp some PHP files and it will just work - there are plenty of services that offer that.
You don't need to shit your files across buckets and provision 20 IAM profiles - noone's forcing you to do that and that is not how you host a web app.
If you're fond of the ftp-based hosting days, those services are available and they will happily take your money.
It's not that it has disappeared it's that vendor-specific cloud has become too normal.
And for the record obviously I'm not advocating for going back to the dark ages, ftp / php / shared hosting also had massive issues, my point was that things were _designed_ to be simple and the model in your head was simple and close to the metal.
If you're joining an existing project today, or like OP's problem/solution you just want to self-host something, maybe even just to evaluate it, it has become a headache.
I've never actually seen a "real" containerised app, one that was 100% agnostic and simple to deploy without multiple exceptions for 3rd party services and so on.
(author here) I'm checking with my team to confirm these came from us, but if so I apologize for this - posts like these should come from a real account with proper disclosure, but also these sorts of requests feel premature for a project like ours that doesn't yet have a sizeable user base.
You are also characterizing another project that was open-sourced (sandstorm) and is under active development as "long abandoned". Open source is difficult and requires a fair amount of cheerleading to engage users and make them part of the community. As a result it's hard to see your project in a positive light.
No, sandstorm was deprecated years ago. I was building a platform that was similar to/inspired by sandstorm, and I closely followed it until its creator deprecated it. They now work for Cloudflare and released the 'WorkOS' project a couple weeks ago through them/for them.
Looking at the issues, do I understand it correctly that you have some way to install directly from repositories if they contain a `cloudinabottle.toml` file?
If yes, regardless of who made the issues, that seems like terrible architecture/design there...
I used to work for this company many years ago, and it's highly unlikely they're running a (centrally organized) spamming campaign of any type. Zack's a good guy and I'm sure he'll get it taken care of promptly.
Yes, but first of all, people make those decisions. And second, unlike those people, you don't need to have dissonant answers, and don't need to lie to yourself.
I don't think this approach is bad. The issues are asking if the project will accept contributions to add support, not demanding the maintainers add it.
Let's assume that they didn't have these container restrictions and could just use an ordinary docker-compose.yml, they'd still probably want to use something like OAuth2.0 for centralised login which a lot of these services won't have.
What would be better, making a massive PR to add support for it, or opening an issue to discuss it with the maintainer first?
It's 11 issues total and by one person, and the project says here in the thread the issue is being addressed. Please put down the metaphorical pitchforks and torches.
I checked, it's an Imbue employee (or someone impersonating one, which seems a bit far fetched). I could could cite my sources but it feels like doxxing / drawing too much attention to the mistake of an individual. My read is that it was a separate github account that they let an agent control.
The person doing this doesn't understand how pull requests work. The issues all say "I have a version in my fork". Open a pull request then! That's the whole point of forks on GitHub. Creating an issue first is pointless spamming akin to the classic "asking to ask". Just seems completely out of touch with open source to me.
It's not spam if it's the first time I heard of it and it's useful. It shows they care about their project. This makes me want to try it out even more.
Meta and Google can spam their unsolicited ads to a billion users but regular people aren't allowed to promote their own projects on niche forums? This is bs. You're the problem here. Self-promoting your harmful values. You're the spammer.
This isn't the hard part of self-hosting, at least not anymore. In the comments here there are lots of examples of similar projects that solve basically the same problem (app selection and deployment). To make self-hosting "easy" we need to solve domain registration, DNS management, and port-forwarding configuration.
This probably requires a project more like OpenWRT that includes an API-driven relationship with a registrar. The lack of a standard (consumer accessible) domain registration API is a huge hole in automating this. If such a project gets some traction, then it could migrate to a physical router that prospective self-hosters could buy. With domain registration, DNS management, and port forwarding all in the router's software, then the remaining hard parts can be sufficiently automated to make self hosting accessible to the average gaming console owner.
Insightful comment I fully agree that the hardest part needs to be automated fully, there's plenty of DNS providers with API access so it can be done. Naming is oftentimes the hardest part we have in tech, I dream of a future we are more decentralized and we have alternatives to DNS to access ressources,see this great text by Andrew Nesbitt about the subject of naming: https://nesbitt.io/2026/03/03/package-management-is-naming-a...
I think the time for this space is here. The appetite to depart from subscriptions and loaning your personal data to ad/ai companies is stronger than ever.
Currently, a lot of this space is docker compose based and simply inaccessible to so many who may otherwise be interested. Whether or not it's this project or another, I hope something gathers enough steam soon to truly break the barriers to entry.
General public is weird because everyone, yet no one, is the general public.
Fwiw I've started to see a shift in many non-tech circles I'm a part of. Especially when you take the time to explain the problems. Many do care, they just aren't made aware of the issues.
The general public will do whatever their friends do. If there was an iPhone charger sized box they could plug in anywhere and have their own personal cloud that can interconnect with other personal clouds, and a celebrity said it was cool to have one, the general public will do it without giving it a first thought.
In my experience just telling people to enable Google / Apple backup for photos is a chore at 5€ a month. And for general public this covers 90% of their needs.
There should be influencers or agitators (as named correctly) to tell general public what distro to install, what server to buy and how block tracking and ads
Precisely. My uncle has been using the builtin Samsung web browser for years on his phone, just because it said "Internet" in the name, and "Chrome" just wasn't a familiar name to him. Most people are like this.
Digital rights are indeed important, but only a small portion of the entire concept of human rights. I can imagine general public places much more emphasis on wealth (re-)distribution policies.
A lumberjack may also argue GP don't care about environment laws if they had timbernews.
True, most people get the full ad driven internet experience and it drives me nuts. Everytime I have to help other people with computer stuff I almost get an aneurysm when opening their browser...
At some point I started just installing ABP/uBO without even bothering to ask/tell them, if I had the opportunity. So far my reads seem to have been correct regarding whether this would conflict with each person's typical web use, as I've never heard back about any trouble.
How does being docker compose based make it inaccessible?
Self hosting implies having hardware and software knowledge to set it up. I agree, having a meta package that would set the system up as systemd would be an even lower barrier. But then again, there are podman commands that do this for you today anyway.
Self hosting could also imply buying a device that just does this with an additional management interface for updates. This could be build around a nuc/nas with above package. It still will require some knowledge to keep it maintained.
Then, you could offer maintaining them as a service again. Maybe there is value in that.
Update: apparently there is https://freedombox.org/ which is actually an appliance for this. Although it is more privacy focused and I don’t see a productivity or photo suite on it.
> How does being docker compose based make it inaccessible?
Because it requires people to also have knowledge about the ins and outs of docker and docker compose. If we are talking about web applications it is yet another layer that has been added over the years. It used to be that you could fairly easily host most things on a old fashioned lamp host (I am talking decades ago) and all you had to know was basic file transferring.
Of course, this was on shared webhosts in a time when VPSes were not really a thing yet or affordable. But, even on a VPS setting up a LAMP stack is relatively straightforward.
Once you add modern dockerized application to that mix you are now still looking at some sort of ingress to do the reverse proxy bit. So while it likely will not be Apache or nginx there will be some sort of layer there in addition to now having to setup docker properly (rootless and all that) and then also making sure your docker compose setup is in order.
It is not difficult *once you know how to* but it is another layer of knowledge and experience people need to acquire. That does make it less accessible for novices.
> you could fairly easily host most things on a old fashioned lamp host (I am talking decades ago) and all you had to know was basic file transferring
Setting up and maintaining a server is easier today than it was decades ago, A LAMP at this time meant a lot of manual setup, IaC wasn't a thing, reproducibility wasn't a goal, versioning was confidential, documentation was scarce and often outdated, out of the box security was lower, ties to the OS were higher. Managing virtual hosts was clunky, updating OS/PHP was risky. I would not go back for anything.
> having to setup docker properly (rootless and all that)
Rootless being the proper way to setup Docker is a highly controversial take. You will mostly get added complexity and a false sentiment of security from it.
> Setting up and maintaining a server is easier today than it was decades ago, A LAMP at this time meant a lot of manual setup, IaC wasn't a thing, reproducibility wasn't a goal, versioning was confidential, documentation was scarce and often outdated, out of the box security was lower, ties to the OS were higher. Managing virtual hosts was clunky, updating OS/PHP was risky. I would not go back for anything.
You are speeding past my point by a mile or two. With a shared webhost you get a ready lamp stack. In the late 90s early 2000s you could fairly easily get a wide array of software running that way. All you had to do is create a database in the hosters control panel, upload the package and you'd be on your way. Later in the 2000s one click installers came along for popular packages making it even easier. In fact, they are still around these days making it extremely easy to install a wide array of lamp based applications to these days.
There are very few options these days to get started as easily these days with modern non lamp tech stacks. The only thing I am familiar with (other than the product presented to us in this post) is pikapods, [which only offers a limited selection of available applications](https://www.pikapods.com/apps). There are a few others, also catalog based, though they more seem to focus on deploying on other platforms for you. Other than that you start to quickly move to more complex hosting solutions aimed at business and scaling. Or platforms that are cloud platforms with all the added complexity to navigate and figure out before you can deploy docker containers. Not to mention ridiculous situation that a few of the ones I know about have pivoted to being "agentic compute providers" whatever that means and certainly will confuse a novice.
Which means that the "practical" advice given is often to "just" set up a VPS. And yes, many VPS providers will provide an image with docker enabled, but that is just the start.
> Rootless being the proper way to setup Docker is a highly controversial take. You will mostly get added complexity and a false sentiment of security from it.
That, in fact, is another layer of complexity people will then have to figure out. Most information I am aware of these days does claim that it is better to run containers rootless or at the very least make sure the user in the container is non root. The fact that we are both convinced of the opposite tells you how confusing it must be for a novice.
The overall point I am trying to make isn't even about the exact details. It is that for hosting something these days there is much more required surrounding knowledge required before you can get started in most cases.
At the same time buying compute is more expensive than ever, and the gap between homemade projects and what's available online in term of speed, functionality and LLM capacity is bigger than ever.
Building the equivalent of Google Photos locally wasn't that hard 10 years ago, given enough tolerance for speed and indexing lag issues. Trying to do the same today will cost two arms and leg and require a lot more overall knowledge of what to compose to get the same result.
The dust will settle and we should go back to a nearer gap in I hope a few years, until the. it might be a glacier age for self-hosting.
> Building the equivalent of Google Photos locally wasn't that hard 10 years ago, given enough tolerance for speed and indexing lag issues.
You could argue it’s much easier on the software side, because self hosting Immich is much easier thanks for AI assistance with setting it up. If you can live without the built in facial recognition feature you don’t need particularly beefy hardware.
I find myself taking on far more ambitious self hosted projects thanks to Claude. Extending home assistant in various ways, deploying a “self hosted Spotify”, making sure everything is fully accessible via Tailscale out of the range of the wifi and so on. Of course the general population isn’t really aware or interested in most of this.
It's about 3~4 years I haven't used Immich so it might have evolved a lot since then, but looking at their current roadmap there is a ton of features I use everyday in Photos that won't be there.
And it's not to fault Immich, on the contrary, Photos is one of the rare Google property where the team is constantly pushing the envelope.
I could combine it with a bunch of external tools to make do, but it would be crazy clunky or would need full sync with Adobe Cloud for instance for the editing part, while doing all the scanning and categorizing locally.
On AI assist...I'm still pausing a lot when t comes to home projects that will be constantly talking to the outside and hold the stuff that is the most private to me and my whole family and friends. It helps me as a research tool, but due to my own restrictions it won't be magic.
> On AI assist...I'm still pausing a lot when t comes to home projects that will be constantly talking to the outside and hold the stuff that is the most private to me and my whole family and friends.
Totally understand this part. I didn’t mean to give Claude code full access to locally hosted environments but rather copy back and forth in your local shell with help from Claude (error messages, helping to plan out the installation etc.)
for self hosted and personal use, compute lasts a good while though. and in the time you would've been waiting to time the compute market, you get to benefit by being less a part of the AI data dragnet.
The biggest difficulty is probably that from my observation, there's a sharp cutoff line somewhere between Gen Y and Z where anyone born before that (and don't work in tech) genuinely have no idea how to navigate their digital life and gets preyed on by those subscriptions. And these people are still a super large portion of the population paying for those subscriptions.
Only Gen Z and later are starting to care and willing to spend the time and effort to self host. All the Gen X and Y people that I know of, including many that are very intelligent and accomplished in their field, literally have no idea how to operate a computer outside of watching youtube, checking emails, and opening Word documents. Ads? They hate it but have no idea how to disable them. iPhone running out of storage and iCloud says I can solve that for $2.99/mo? They would be like IDK what that is but sure I'll pay that $2.99 if that means I can record more videos of my kids.
I really hate this situation, and I try my best to help out the folks around me who I see are getting ripped off (either they don't know or they know but think that's what it is). But still, it's really hard to communicate or teach those people when the skill of operating a computer has become intuition and human nature to me. I really can't put these things into words on the fly that would help them understand :(
> Only Gen Z and later are starting to care and willing to spend the time and effort to self host.
I'm not sure what you are seeing, but what I'm seeing is widespread teach illiteracy in Gen Z outside of their smartphone. Gen Z and younger mostly grew up with smartphones as their primary devices and with little contact with a laptop or desktop computer (and even then confined 99% to browser usage).
> Only Gen Z and later are starting to care and willing to spend the time and effort to self host.
I can't quite confirm that. My younger siblings' classmates (still high school students, born >=2010, non tech average people) don't give a shit on these topics and behave identical to the Gen X and Y described.
Looking at my younger sister, I'd risk saying it's the same in all generations. I'll even say more: I think earlier generations had a general thought of "computer consists of separate parts; you can buy them separately and replace if needed / want better performance", even the less technical ones. But now everything is a black box (therefore e.g. why not overspend and always buy a black box from Apple if that's fashionable now).
But maybe that was kind of related to times and the place – where I live people needed to be a bit more savvy, so thought like "why you buy an iPhone if Xiaomi can do the same 4x cheaper; if you chose the right model you may even have a good camera too" was popular even in non-tech circles.
But yeah, now that hardware is a bit more of a commodity and such tradeoff might give you a bit more adware with a bit less convenience, maybe it's different. But the next generation's understanding of computer/phone as something else than a magical black box is gone.
Yeah it's not my point to say Apple is bad – their laptops are now without competition on build quality, battery life and performance; and iPhone is really solid, and was probably the only good UX back in the day. But it's also pricey (and building antipatterns for repairability and interconnections other vendors happily copied later), and back in the dat it was just natural to be "savvy" – and that meant understanding how much juice you'll get with configuring something with that RAM, HDD vs SDD and whatnot, or that getting phone with SD slot gives you more space for your photos, and it didn't matter it's slower than whatever flash phone manufacturers are using.
Apple popularised the idea of "just buying a computer", which took away some understanding in the common public. It happened somewhere during my generation, and it's just ubiquitous in the following one.
> Only Gen Z and later are starting to care and willing to spend the time and effort to self host.
Yeah, you’ll need a lot of supporting evidence for this claim. From my personal and professional experience, this doesn’t track. And given how online the younger generations are, it tracks even less. I think there might be a bias towards tech bubbles in that statement.
Or, alternatively, I was a lot more willing to put in the time to self host before I had more money and less time. If it's truly important it's not in public. If it's public, I don't have time to keep up with security patches if I'm not being paid.
Sandstorm had a radically more innovative model of hosting: instead of helping you host apps, each document was its own instance. This was really interesting, but as this article notes, did need deep integration with the apps.
I'd be interested to see if your more pragmatic approach plays out. Being able to start by taking apps "off the shelf" largely unmodified, then gradually adding integration via standard proxy features, seems sensible.
In any case, doing single sign on between apps is just a very sensible and worthwhile place to start.
This is a great idea and I wish it success. Self-hosting shouldn't be a nightmare of researching and setting up 20 different applications.
Is there something similar in progress for a "tech company tech stack"? As in, rather than trying to assemble your own custom infrastructure by finding an RPC system, permissions/group manager, credential management, storage, database, service discovery, job management, monitoring etc. one "opinionated" stack that you can easily deploy, as long as you're OK accepting their choices, with all these parts already bundled and wired up.
Ruby/RoR doesn't really solve the e.g. monitoring problem, does it?
My goal is something that would work for startups that plan to grow beyond a single person/single server project. If you build the architecture for a too small size, you start running into walls as soon as you exceed that size.
But even if you are small, you probably want some kind of Grafana/Prometheus monitoring to tell you what's breaking. You want your framework pre-wired so it automatically reports data (e.g. requests/failures per service) without you having to set it up, because it it isn't automatic, you probably won't get around to setting it up until it's too late. You also want some kind of build system, CI/CD to handle deployment. An easy way to set up staging environments would be nice. If you don't want to use a hosted forge, then a self-hosted forge connected into all this.
My idea is to have one somewhat commonly adopted stack, where most of the stack "self-deploys" so you don't have to set up, connect, and coddle all of these services. If you want to deploy something within the stack, you're somewhat limited because you have to do it "the stack's way", but in exchange, once you've set it up, adding a staging environment consists of not actively disabling the default staging environment that the stack would set up for you otherwise, and once you've deployed your service, it's already pre-wired into your monitoring.
Popular packages would then over time likely get packaged for this stack, with service-specific monitoring exports (e.g. the postgres container could export query details rather than just the default-collected values like CPU usage and requests-through-the-standardized-RPC-framework).
Huh? Which of the things on that list are only needed at the billions of users scale? I'll give you "service discovery" and "dozens of services", sure, but everything else in there seems like a pretty standard need for a SaaS app that feeds a company of more than 10 people?
"We (Imbue, the company I work for) also offer a managed version, which I think is really important to making this widely accessible - and it gives us a straightforward business model to support the project."
Looking at your hosted page, I see no reference to backups. I see in your docs reference to backup, but you should definitely offer some sort of turnkey, appropriately-marked-up backup solution. Configuration difficulty is what kills self-hosting on the front end, updates make it hard over time, but when it all dies and then I have no backup is when I give up.
I can't find any reference to disk size limits anywhere. Can I host Immich on this? Can I host my media server? What will it cost? Surely not $10/month for my media collection. I'm not a hoarder and mostly have stuff ripped from my personally-owned media, which limits the size, and you're still not hosting that for $10/month. I see you have Jellyfin in the set of apps but I don't know what it will cost. The CPU & RAM limits I understand from the deploy page.
Oh, and I'm specifically referring to your hosted service here.
(author here) Thanks for flagging, I should make this more clear. Our managed instances have pretty small disks (~50GB), but there's a way to link a S3 bucket to your instance to use for bulk data storage. Apps that store bulk data (like immich/jellyfin) should automatically put it in the "archive data tier" which can be configured to go into this S3 bucket instead of local storage. We're planning to make this (and backups) an auto-configured part of our managed instances - billed separately (so you pay for just the additional storage you use; cloudflare R2 (S3 compatible) at-cost is like $15/TB/mo so it should be in that neighborhood).
There seems to be a lot of variance between stated and revealed preferences around self-hosting.
It often seems like presenting the image of being autonomous to our peers seems more important than actually achieving it.
It takes a lot of energy to replicate what AWS and friends have done once we factor in concerns like the passage of time and entropy. I've never been able to keep a media/NAS appliance alive for much longer than 3-4 years. Inevitably, there is some kind of catastrophic event and I have to start all over with new vendors, etc. Even without any data loss this gets old. I promise you get tired of this after a while. It might seem like that would never happen and then one day it does.
You can get so much more done if you can actually afford to use the cloud. I have a really hard time believing that many people are genuinely winning on total cost of ownership with self hosting.
How are you backing up 100TB of data? Have you factored the consequences of catastrophic data loss into the economics? How much value would you lose if all your data was gone?
There's no way you are consuming this much content actively. You could store all of it in S3 deep archive for $200/m (100TB) and maintain a tiny fraction in the standard resource pool.
Yep, even with something like NextCloud or ownCloud it gets tiring pretty fast. I do get the appeal of handling everything on your own, but it also brings any of the downside of handling everything by myself. I just need a working cloud storage with sync, redundancy, and availability. Can I get it up to spec? Definitely but it will cost more both in time and money than getting OOTB solution.
I gave up sync and availability for sensitive data to at-rest encryption. Mundane photos/documents can stay on Google Drive, for now. I wish there's a better solution.
> even with something like NextCloud or ownCloud it gets tiring pretty fast
I haven't touched my nextcloud installation in maybe 9 months and I've been running it for about 1.5 years.
When there is a problem it's now very easy to fix, I just point an agent at it. It syncs to my phone, my laptop, and several other people's as we use it for a small business.
It's not perfect but neither were any of the commercial things we'd tried before.
This is a great project! Yes, the personal cloud is coming and it's going to be for everyone.
I'm working on a project with similar goals but some different design decisions - instead of the typical containers I'm going for thin-client apps that hit a common data layer built on a fully serverless architecture. Not ready for production quite yet, but for those interested: https://starkeep.app/
This pitch is somewhat interesting, but, much like Sandstorm, browsing the library of pre-built apps kind of leaves me cold. It's too much like browsing a rather tiny mobile app store. There are maybe three apps that I might be interested in.
Since we have AI now, I think exe.dev's pitch is better: they provide Linux VMs, a web proxy, and integrations. You can ask the AI to build whatever web app you like. I'd love to have exe.dev, but running on my Mac Mini.
I'm surprised there's no such thing as a self-hosted deployment spec. An opinionated docker-compose file (or similar) with well defined inputs, outputs, and requirements that works for the average use-case.
I'm glad to see this, auth in particular is a real sore spot in self-hosting. In terms of the available integrations, Home Assistant feels like a big missing item - it's the core of many folks home server deployments.
Congratulations on the launch, I 100% agree with your vision:
> run on your instance (it's really easy!)
I silently published AliaJS a year ago, since it's still in alpha in my opinion., But I keep releasing improvements, coming in the next few days, a one liner CLI turnkey quickstart script: `npx aliajs new`. I'll also provide a clickable user interface (Electron app). This is exciting, happy to see where the community is going with cloud tools that empower the individual actors.
If this can largely automate the backup and update side of things, then it seems like a great middle ground for people like me:
I’m trying to self-host as much of my stuff as possible, but don’t have time to tinker like I used to. Hence updates, backups (etc) fall by the wayside in favour of “set and forget”.
selfprivacy appears to be limited to a handful of services. e.g. It is not clear to me if I can host postgresql with it. i.e. It is not a general purpose container hosting product.
If your "opt-in platform features" and "interface to allow permissioned access to data and capabilities between different apps" is more expressive/discoverable than eg Cloud Foundry's "Service Broker" approach[0], then I am pretty excited! I run a lot of disparate services which don't interoperate except through explicit workflow automation pipelines (I use ConcourseCI to eg upload images to Immich [1] albums, but others might use n8n[2] for the same purpose).
The "workflow automation" approach is a lot of resource overhead and broker-config maintainance, but my kingdom to be able to arbitrarily compose apps' states, eg commutimemap.com + Craigslist.
Between podman docker and general VM's there hasn't been a better time to be selfhosting. I tend to find any abstractions on top of this to be quite limiting and difficult to extricate yourself once something goes wrong.
Making self-hosting really accessible isn't that easy, even if it's easy to setup the server machine itself.
One needs to make their server machine accessible to everyone, which isn't generally possible due to how networks work, one needs a white IP address and making sure no incoming connections are rejected by the internet provider.
Also one needs a domain. Obtaining it requires some bureaucratic burden, costs money and pricing isn't always transparent.
These barriers are high enough, so that common people can't create/host their own sites. Only skilled enthusiasts or professionals can afford having their own site.
People choose not to because they see no need to, but if they put some time, effort and not a lot of money then those barriers are not so high.
I took the trouble to get a driving license because I saw value in that. I also took the trouble to learn to set up my own stuff on a VPS because I saw value in that too.
What's a "white IP address"? It is, sadly, more difficult than it should be, though. When everyone got online in the 90s they actually became bottom feeders and not true internet citizens. Not much has changed in 30 years. IPv6 is necessary, but the world also sucks now so people need to know what they're doing with firewalls etc. Domains are not too bad now, there are some decent registrars now like Porkbun.
"white IP address" is an address that your internet provider gives you and which is accessible from the whole internet, not just some address local for the provider's network and hidden behind NAT. Since IPv4 addresses are scarce, most providers don't allocate them directly to their customers.
An unique IPv6 may be theoretically assigned to each end device and thus solve the accessibility problem for locally-hosted servers, but I doubt internet providers do this in practice and I am afraid that many providers don't support IPv6 at all.
That's usually called a public IP address, aka a real IP address.
IPv6 works exactly how you describe, that's the whole point of it. No NAT, just IP addresses. Some gaming consoles use it for peer to peer multiplayer so it is in demand even by normies. One of the problems is competition is stifled in the ISP market, by monopolies and ridiculously long contracts.
Happens. Had an idea (simple and stupid one), built it (with LLMs) went to register the domain. Found out somebody had the same idea and already put it there :)
I'm trying to understand the difference between this project and FreedomBox. I mean it's great to have options, but have any of them looked over that way? Heck, FreedomBox is even built into Debian now.
What's wrong with coolify?
Their ecosystem help start a service with pretty much zero issues.
And they also show that maintaining a large amount of click-n-deploy services can't keep up with the releases of all of them.
They hit the sweet spot of having everything in a second and maintaining it with ease over time.
I really like the idea, and I would like to see Tailscale evolve Aperture in this direction. Tailscale is already an easy way for anyone to connect their devices, which is essential for any sort of "personal cloud", and Aperture, while initially something of an AI gateway, is also facilitating connections to other services and apps.
If you're building a personal cloud, you also want your AI connected to it, but probably with some degree of management. Aperture already provides a fair amount in this area, and probably with a connector for Cloud in a Bottle, could give your AI safe access.
I did a few pitches related to this at Nasscom Startup warehouse and IITM RTBI. Though this was welcomed by the panel members but it never took off due to lack of capital for such a startup during those times in India. I had to abandon and focus on my day job.
Poking around and have to ask an obvious question: What's the difference between this and Canonical's Juju from twenty years ago? Isn't this just the same thing, but with newer tools?
Are there currently any per-app CPU or memory limits? If not, could an app with a memory leak or high CPU usage affect the entire server and other applications? Are there any plans to enforce resource limits using Podman/cgroups?
Now the key question, can the hardware be made accessible to everyone. Its definitely an improvement to make self hosting software easier but the process of setting even a raspberry pi for an average consumer interested in self hosting is still a barrier. They probably will be able to figure it out via youtube and some reddit posts but there should be an easier process or way
(author here) I am really excited to make pre-configured Raspberry Pis that people can just plug in at home, and have it work out of the box. It'll take a bit more work to make it seamless but we're definitely aiming in that direction. It's a shame how expensive Pis have gotten recently though with the memory shortage.
That is cool to hear. I know lots of folks who would be genuinely interested in this who don't have the technological chops to set up a self hosted system. One angle i have heard is degoogling and having more privacy in their data. I am really genuinely interested in this venture. I had the same idea about a year ago but was not in a place in life to act on it. I think even with the PIs being expensive because of the people will still buy them. Especially if they are seamless or near seamless.
>At the core, it's just an Ubuntu machine with a web server that hosts a dashboard and routes HTTP(s) requests to containerized apps.
So no fail over/redundancy? I think at minimum it should be two machines, so one can break. That is one of the important features of cloud applications as far as I'm concerned.
You don't have to deal with the problem of a single computer breaking.
This also adds a lot of moving parts and failure modes. For self-hosting I’d rather have downtime on a simple system that’s easy to fix rather than a complex setup that stays up but needs more maintenance when some component fails.
> 53 is required because instance runs its own authoritative DNS server.
Are you planning to offer alternative solutions for this, e.g. pointing a wildcard A record at the server running the instance? I'd rather not run a publicly accessible DNS server.
Interesting project! I've found self hosting a lot more approachable with the advent of AI to help with inevitable errors. I run every new app in its own service account and as a rootless podman quadlet. There are three main difficulties that I come up against with every app. First is backups, or more accurately restoring data. My understanding is that just taking a snapshot doesn't always give you a working restore point because an app could be mid-database migration or something like that. Second is updates, and third is accessibility outside the network. I am slowly working on my own solutions, interested to know how you tackle those though?
This happens with making many small to medium level resource hungary apps, for personal usage, run on one VPS which is not a heady duty machine costing heavy duty money. I have tried this on similar machines 2GB RAM and 1-2 VCPU and after 2-3 apps it starts swaying like a drunkard in slow motion even in that SSH session. But at least this one seems to be better than something like PikaPods, in combo pricing regard (I am not saying one is generally better over the other), where the pricing is rather per app.
Your headline is literally the slogan of Magic Cloud. It's been around since 2019, and does this "exact thing" - Basically, "your cloud, on premises" ...
This is neat! I've been building something very similar for personal use. I may lift a little bit of the app manifest part.
I'm a little surprised that there's just one backup app, instead of each app coming with its own backup sidecar. To backup Immich, for instance, requires coordinating between its four different programs. I guess I'll read more about how that backup app works too ha
Has anyone else found NextCloud to be slow and unreliable? I've been using it for the last three years (switching over from OwnCloud before that), and it's never missed a beat. Straightforward to set up, decent linux desktop clients, has mobile support that's also been rock-solid, and basically does what it says on the tin. Doesn't feel remotely enterprise targeted to me either -- it feels very much targeted towards home users.
Thanks for bringing this up, I was going to ask the same.
I haven't heard any complaints about NextCloud, they've added some enterprise features, but all in a positive way, from what I can tell, not detracting from home and personal use.
Running the authoritative dns for the zone seems elegant, although wouldn’t that imply you absolutely can’t use cloudflare or similar services to avoid ddos/bots?
We need gmail, docs and sheets replacements. With AI, maybe people can develop solid alternatives very quickly. And Linux phones.
Trillion dollar companies try to extract more and more from us, the only response is for us to develop alternative solutions and continuously chip away at their strengths- what made them monopolies in the first place.
I had rather good experience using agents to setup and deploy own cloud, Jellyfin and co. I experimented also getting a VPS, just giving the LLM the ssh keys and having at it. It’s pretty good.
If the AI stays afloat, then I think the future lies somewhere there. Not too sure about the security side of the things …
> just giving the LLM the ssh keys and having at it. It’s pretty good.
I'm mostly fine letting AI write code because its easily auditable and you can follow changes through the Git history.
Whereas, it you let the AI go free on a server, you mostly have no idea what it did and where, so it's quite hard to audit and even harder to try and fix things.
So, unless relying on a declarative paradigm like NixOS does, I'm not ready to give AI the keys to my castles
While admittedly this can be a bit risky, there's a lot less possible blast radius or thing that can go catastrophically wrong if you give the LLM the ssh keys and sudo access on a KVM VM (or equivalent) that's been created as a blank slate exclusively as its playground. I have a template debian 13 KVM VM that can have its ssh host keys and hostname wiped, other unique per-node things, and duplicated with a basic bash script in a couple of minutes to deploy for home lab testing.
I'm fine with giving a "smart" self hosted LLM like qwen 3.8-flash-next Q8 access to it to do things in opencode.
Don't give it the keys to any castle but give it access to one specific containerized thing...
I'm saying a staging/testing environment is a good place to prove your specific configuration of "smart" LLM isn't going to do something wildly wrong, before you even think to trust it in a production environment. And as a place to develop things like playbooks and similar documentation to feed into an LLM's context for ongoing maintenance and operations of something in production.
This is not me saying security doesn't matter (because it does) but having everything not publicly accessible and only accessible over Tailscale or Wireguard makes me slightly happier.
Like the real ones, digital clouds can take many shapes.
Sometimes it means "rented virtual resources", sometimes it means "stack of intertwined services", sometimes it means "SaaS", sometimes it means "alternatives to SaaS"...
An aside: Fantastico was such a wonderful piece of software for me to learn and toy and tinker with web stuff. I was so impressed by the simplicity of it. (I phased out of the shared scene a almost two decades ago; I guess everyone moved to Softaculous, https://softaculous.com/fantastico/)
I think what this needs to be truly accessible by general public is a mobile app (most people don’t have computers) and to be able to deploy it (including setting up domains) from there. Payments would definitely be a problem because of the various app stores’ rules.
Yeah, it was called Openhost for a while before changing to Cloud in a Bottle. Either filename works.
It proxies requests from the user to installed apps, and adds a header 'is-owner'. Apps have to be built to respect that header - some apps do this by running their own little proxy/sidecar that will detect that header and inject saved credentials.
I recently bought a motherboard for my first self made pc. Six to eight sata slots is already enormous and the fact that you pay once and use your hardware freely opened my eyes. I was paying a subscription for cloud 1 tb for a trivial service. I am now hoarding my torrents worry free and plan to convert it to NAS. However i do still use my onedrive plan shared with three friends for 10 dollars for sharing large files till i set up my own nas with a good permanent net connection. The other issue is that I’m renting currently and if I’m changing countries I’ll have to rely on the onedrive again
How is this different from say Docker? I procrastinated getting acquainted with the latter for a long time because I thought it was more for industrial-scale infrastructure, but when I finally wound up using it I was surprised at how easy and low-maintenance it was.
You don't need docker anymore - it is safe and fast to deploy as systemd services.
And yeah AWS and the likes made for big money spenders with gigantic DevOps teams, not one person handling everything.
We at DollarDeploy were advocating that for 95% of your usage needs you don't need anything but one server and if outgrow it just switch to a bigger one.
I think one cloud in a bottle should be solved differently - apps deployed independently but additional thin layer for MDM - so logins and core data is at one place.
Imagine if your self hosted wordpress, outline, nextcloud and etc share same logins and access levels, bootstrapped with same information without the need to type it for every app.
I picked it a few years ago for much the same reason as anyone else (sick of this shit), and it's main attraction to me was it being a turnkey solution that focus security so i wasn't as likely to completely fuck everything important up.
I think a "simple" installation package would be very attractive to most people, and while cosmos has a lot of growing to do in order to be that, I'm still pretty happy with it.
I'm even more happy to see more in this space, because I'm just at the point of "do i stick with cosmos or do i start rolling it all myself" and god the leap is terrifying if you're thinking of exposing to the internet. I get it, but at the same time it feels like you're always one missed config away from a potential nightmare, and that's after the "welp guess this is my second job" problem.
accessible self hosting is already here, its called 'claude' or 'codex' you basically start it and tell it what you need, dont even have to know any software names.
a similar project which i think is a lot better than this (in fact it's so good i'm jealous of its genius) is https://exe.dev. It feels like something that hasn't really hit the mainstream yet but I suspect everyone will be talking about soon.
i think you're right to call me out. being open source/self hostable is a big plus of this project. outside of that, exe.dev is a fantastic way to deploy pretty much anything; pay a subscription for total compute and distribute that among VMs however you would like, host your own stuff, as simple/as complex as you want it to be. just infinite versatility and a fantastic user experience imo.
The unified auth + inter-app permissions are the real differentiator vs Coolify/CapRover-style container hosts. Data tiers (local DBs vs S3/R2 archive) also look like the practical way to make Immich/Jellyfin viable without giant managed disks.
How does it deal with storage? Storage is always the weakest link in self hosting. Having a bunch of stateless containers is ultimately just a fancy docker compose file. Still valuable, but you need a proper story for storage. Ideally all storage would be on individual volumes per app and all backed up etc.
It's sad that open source / open-internet projects always have a clunky design. Here, the main screenshot, at the top, uses a monospaced System font. You might as well display a terminal and it's a wrap. To appeal to broader audiences:
- You both need to trigger the potential OSS contributors, with references to Debian, Ubuntu maybe, and appeal to big donors, which is another topic entirely,
- And ALSO have a design that triggers the broader audiences and therefore, very "turnkey", very packaged, very "Comment like and subscribe", one-click install on your NAS, etc. Privacy is then a characteristic but services are the real features.
Meh. Maybe I'm a grinch, but I don't see this as easier. I have a little NUC running Ubuntu. Putting services on it is easy: PiHole, OwnCloud, Wireguard, etc.
> coolify: hosts containerized apps, but every app is an island with its own login and little integration with the host or other apps.
That’s not an issue tho, I want each application to be a separate login, so I can have one pointed to a different subdomain or domain not all in one login and location.
I remember back when I first got into self-hosting (over a decade ago), I had a Netgear READYNAS. People made a small amount of plugins you could install. But the CPU was ARM before that was cool (I think mine was actually SPARC!) so it was a lot of effort to get things to compile, so plugins were usually quite outdated.
Then I decided to painfully break out of vendor lock-in, built my own NAS with FreeNAS which was all the rage (still attached to a vendor, but at least I could control the hardware). This was before Docker really took off - the plugins were installed in FreeBSD jails. It worked for a while, but again, plugins could be woefully out of date and broken, upgrading the OS was a pain and would break all your plugins.
Through the 10+ years of this... I now follow two simple rules:
- separate your network storage and application hosting. Yes, it complicates things a little bit with NFS setups but it is a forcing function for a more resilient setup
- use the docker container provided by the maintainers or LinuxServer.io. Vendor maintained wrappers can be initially helpful but end up as a form of tech debt when they're abandoned or neutered - especially when they're freemium and the company starts looking to squeeze.
The quiet part of self-hosting is that it shifts the responsibility of security to the user. I'm sure cloudinabottle has more sensible defaults than provided docker containers, or builds in reverse proxies etc, but I doubt they're offering to take on liability for data loss or breaches.
The problem I see you'll face are two-fold:
1. Projects like this have the power users self-select away from it and those who need a lot of hand-holding to self-select into it. If I know how to configure and deploy a docker container already I have no incentive to contribute. ReadyNAS got around this by having folks charge for their plugins (that were just OSS projects packaged up for their OS) but then it ruins the appeal, they likely only got away with it because they were only a couple of bucks and you were already locked in to the ecosystem via the hardware.
2. If the hosted aspect actually makes you money, required for the project to be continued long term, capitalism will ensure that incumbent cloud providers take that away from you by offering ready-made instances at your cost-price, like they did with redis, elasticsearch etc.
Note that these are only issues if you're motivated by making a profit, or even a cost-neutral project. But if this is a charitable exercise backed by an entity that doesn't need the money, I wish you all the best - more things that let people dip their toes in are good! The cloud is all rent-seeking subscriptions and even with the recent supply shortages: fast, small, low-power compute is incredibly cheap these days, especially old business/mini machines.
IMO, one way to retain the power user crowd is to do the hard parts that they might have skipped themselves. For a couple examples:
- after selecting your observability apps, every _other_ app could automatically configure centralized logging, its own dashboard of metrics, etc
- the host OS could ask the user simply for the backup destination (S3 url creds, attached local disk, SMB share, etc) and every app is again automatically configured with backups
- the host could have a control panel to roll back apps between versions (maybe it's FS snapshots or something)
- everyone can use containers, but if the project went through the extra effort to make each app its own VM instead, that could be worth something
- if there was a companion Android/iOS app for management and (importantly) alerting?
---
That doesn't really solve the monetization issue you described, but I do think you can still get powerusers on board if you handle even harder problems than they'd want to take on themselves. Or...harder problems than they'd risk taking on themselves if their family uses what's being hosted, for example. Less tolerance for downtime
No offense, but this is not accessible to everyone. Seriously, take a look at the setup instructions and tell me with a straight face that a 4 year old could set this up.
How do I reach out to you? We're building something that you might want to be a part of. (The "Safebox" comes with all the software you need, and you can just clone its AMI on AWS etc.) Would love to have a conversation.
LLMs can be self hosted though. Using Claude to build a self hosting platform is a bit like telling people they should be vegan while you're eating a bacon sandwich.
> In the pre-cloud days, open source worked - authors distributed their software, and everyone "hosted" it for themselves (i.e. ran it on their own PC)
This is just rose tinted vision of the past. None of the software of the past had the capability, reliability or robustness of modern sass.
Yea. When people talk about how simple things were in the past, I think they oblivious to the fact we were all writing out X11 configs by hand and having them break in all sort of strange and interesting ways. Open source has always been very "I gave it to you for free, I'm not going to hold your hand".
I've written X configs by hand, but only to get a few extra pixels of overscan. I've never needed to do this. My experience has always been that things just work. The UI has never been great, in that I need more explanation than the built-in manuals provide – unlike, say, Windows 95, where you can learn everything you need to know by clicking around – but it's not hard to avoid breaking things, and it's not that hard to learn to do new stuff if you have a good book (or, lately, blog post) to consult.
In the age of LLM agents, still going for Docker/Podmam on anything besides local development box seems like a weird choice.
Docker has poor tooling for network level security between the containers, has issues with different runtimes per container, etc.
It is just a bit primitive if you want to expose multiple services to the internet on the same server. One of those apps will get compromised and then all the others will follow.
If you want a decent self hosted server, ask your frontier LLM agent of choice to configure kubernetes (on something like k3s) with mandatory userns mapping so nothing runs as root on the host, default deny firewall so inter-container communication is as locked down as possible, and if your router supports, set up VLANs so none of the containers can access your other devices on the LAN. Use something like backrest to handle backups, alertmanager and Grafana for monitoring, Keel for auto updates. Also consider separating ingress for public and internal services and use Tailscale with split DNS to acces the internal entrypoint. Set up Crowdsec as WAF and subscribe to their free blocklists to filter out bots. Ask it to set this all up using Ansible, so it can be maintained.
While this would be extremely time consuming to set up and maintain by hand, an agent can do and test it in a few hours.
Yes, kubernetes makes it much easier to configure proper firewall through network policies.
Docker has networks but there is no good options to limit it beyond those and it is extremely basic and basically leaves everything open between your proxy and app.
Containerisation was supposed to mean host anywhere, literally redeploy a complex set of services and their connections on any cloud provider at the drop of a hat. That is what a f**ing shipping container is, you rock up to any port in the world and the same container is lifted by any crane onto any ship or truck.
Amazon, Google, Microsoft - these people have sold vendor lock-in to the very segment of tech society that should have been fighting it tooth and nail. 20 years ago you ftp'd some PHP files and it just worked, now you have to figure out 20 IAM profiles and shit your files across buckets because everything must be 1000000x scalable out of the box.
No joke I was building a static firebase site the other day and just wanted a simple way to password protect it (like http auth) for staging so my client could see it - of all the useless shit firebase tries to lock you into they can't even do something as simple as basic http auth without a shit show and spinning up a cloud run instance or something to check a static password.
Yes we 100% need fix hosting, everything should be portable, simple, generic.
reply