Edit: and to the peer comment regarding S3 vs self host: regardless of 10x cloud cost, it's still 10x volume. Where 1TB local would do, now you need 10TB (10x the cost)."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Crunchyroll is destroying its subtitles"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://daiz.moe/crunchyroll-is-destroying-its-subtitles-for-no-good-reason/"}},"_tags":["comment","author_ramses0","story_45754509"],"author":"ramses0","children":[45760258],"comment_text":"Someone else was saying they maintained burn-in subs for devices that didn't handle ASS renderers. Even without accounting for the burn-in versions, using non-standard subs still bumps them off of commodity subtitling services and limits distribution/syndication.
Edit: and to the peer comment regarding S3 vs self host: regardless of 10x cloud cost, it's still 10x volume. Where 1TB local would do, now you need 10TB (10x the cost).","created_at":"2025-10-30T11:30:29Z","created_at_i":1761823829,"objectID":"45758838","parent_id":45755815,"story_id":45754509,"story_title":"Crunchyroll is destroying its subtitles","story_url":"https://daiz.moe/crunchyroll-is-destroying-its-subtitles-for-no-good-reason/","updated_at":"2026-03-05T22:58:28Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"johnklos"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"The whole push to the cloud has always fascinated me. I get it - most people aren't interested in babysitting their own hardware. On the other hand, a business of just about any size that has any reasonable amount of hosting is better off with their own systems when it comes purely to cost.
All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding, but serve to introduce doubt to non-technical people and to trick people who don't examine what they're told.
What's particularly fascinating to me, though, is how some people are so pro-cloud that they'd argue with a writeup like this with silly cloud talking points. They don't seem to care much about data or facts, just that they love cloud and want everyone else to be in cloud, too. This happens much more often on sites like Reddit (r/sysadmin, even), but I wouldn't be surprised to see a little of it here.
It makes me wonder: how do people get so sold on a thing that they'll go online and fight about it, even when they lack facts or often even basic understanding?
I can clearly state why I advocate for avoiding cloud: cost, privacy, security, a desire to not centralize the Internet. The reason people advocate for cloud for others? It puzzles me. "You'll save money," "you can't secure your own machines," "it's simpler" all have worlds of assumptions that those people can't possibly know are correct.
So when I read something like this from Fastmail which was written without taking an emotional stance, I respect it. If I didn't already self-host email, I'd consider using Fastmail.
There used to be so much push for cloud everything that an article like this would get fanatical responses. I hope that it's a sign of progress that that fanaticism is waning and people aren't afraid to openly discuss how cloud isn't right for many things."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Why we use our own hardware"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.fastmail.com/blog/why-we-use-our-own-hardware/"}},"_tags":["comment","author_johnklos","story_42485124"],"author":"johnklos","children":[42486528,42486590,42486596,42486619,42486629,42486671,42486693,42486726,42486741,42486772,42486836,42486859,42486875,42486929,42487023,42487059,42487132,42487146,42487244,42487245,42487272,42487353,42487401,42487444,42487449,42487454,42487493,42487538,42487605,42487635,42487650,42487657,42487736,42487785,42487859,42487872,42487982,42488068,42488079,42488126,42488180,42488278,42488358,42488442,42488779,42492441,42495591],"comment_text":"The whole push to the cloud has always fascinated me. I get it - most people aren't interested in babysitting their own hardware. On the other hand, a business of just about any size that has any reasonable amount of hosting is better off with their own systems when it comes purely to cost.
All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding, but serve to introduce doubt to non-technical people and to trick people who don't examine what they're told.
What's particularly fascinating to me, though, is how some people are so pro-cloud that they'd argue with a writeup like this with silly cloud talking points. They don't seem to care much about data or facts, just that they love cloud and want everyone else to be in cloud, too. This happens much more often on sites like Reddit (r/sysadmin, even), but I wouldn't be surprised to see a little of it here.
It makes me wonder: how do people get so sold on a thing that they'll go online and fight about it, even when they lack facts or often even basic understanding?
I can clearly state why I advocate for avoiding cloud: cost, privacy, security, a desire to not centralize the Internet. The reason people advocate for cloud for others? It puzzles me. "You'll save money," "you can't secure your own machines," "it's simpler" all have worlds of assumptions that those people can't possibly know are correct.
So when I read something like this from Fastmail which was written without taking an emotional stance, I respect it. If I didn't already self-host email, I'd consider using Fastmail.
There used to be so much push for cloud everything that an article like this would get fanatical responses. I hope that it's a sign of progress that that fanaticism is waning and people aren't afraid to openly discuss how cloud isn't right for many things.","created_at":"2024-12-22T14:29:34Z","created_at_i":1734877774,"objectID":"42486515","parent_id":42485124,"story_id":42485124,"story_title":"Why we use our own hardware","story_url":"https://www.fastmail.com/blog/why-we-use-our-own-hardware/","updated_at":"2026-06-10T04:06:22Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"maxthegeek1"},"story_text":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["n8n","cloud","cost"],"value":"Hi HN, we've released Dittofeed v0.4.0, a significant update primarily focused on facilitating self-hosting. Dittofeed is an open source (MIT licensed) alternative to platforms like customer.io, mailchimp, klaviyo, iterable etc.
Self-hosting is particularly useful if you:
- Want to evaluate Dittofeed without a long-term commitment
- Prefer fixed, non-volume based pricing models
- Aim to keep all personally identifiable information within your own infrastructure
In this version, we introduced 'Dittofeed Lite,' which merges the dashboard, API, and worker services, simplifying deployment, along with providing an easy auth setup.
We've also configured a 1-Click Render deployment. The Render setup comes at a fixed cost of $39/month. However, by using alternative hosting solutions for the Postgres and ClickHouse instances (neon, clickhouse cloud), the monthly costs can be reduced to under $20.
We personally feel that there\u2019s a big problem with how existing platforms handle pricing, charging insanely high prices with low contact limits, while restricting access to really basic table stakes features.
Excited to share this work, and hear your thoughts and feedback!
Github Repo - https://github.com/dittofeed/dittofeed
Demo - https://demo.dittofeed.com/dashboard/journeys
Docs - https://docs.dittofeed.com/getting-started"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["self","host"],"value":"Show HN: Dittofeed \u2013 1-Click deploy, self-host Mailchimp alternative"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/dittofeed/dittofeed"}},"_tags":["story","author_maxthegeek1","story_37572743","show_hn"],"author":"maxthegeek1","children":[37573604,37574515,37575787,37575843,37576031,37576218,37665472],"created_at":"2023-09-19T16:53:19Z","created_at_i":1695142399,"num_comments":29,"objectID":"37572743","points":100,"story_id":37572743,"story_text":"Hi HN, we've released Dittofeed v0.4.0, a significant update primarily focused on facilitating self-hosting. Dittofeed is an open source (MIT licensed) alternative to platforms like customer.io, mailchimp, klaviyo, iterable etc.
Self-hosting is particularly useful if you:
- Want to evaluate Dittofeed without a long-term commitment
- Prefer fixed, non-volume based pricing models
- Aim to keep all personally identifiable information within your own infrastructure
In this version, we introduced 'Dittofeed Lite,' which merges the dashboard, API, and worker services, simplifying deployment, along with providing an easy auth setup.
We've also configured a 1-Click Render deployment. The Render setup comes at a fixed cost of $39/month. However, by using alternative hosting solutions for the Postgres and ClickHouse instances (neon, clickhouse cloud), the monthly costs can be reduced to under $20.
We personally feel that there\u2019s a big problem with how existing platforms handle pricing, charging insanely high prices with low contact limits, while restricting access to really basic table stakes features.
Excited to share this work, and hear your thoughts and feedback!
Github Repo - https://github.com/dittofeed/dittofeed
Demo - https://demo.dittofeed.com/dashboard/journeys
Docs - https://docs.dittofeed.com/getting-started","title":"Show HN: Dittofeed \u2013 1-Click deploy, self-host Mailchimp alternative","updated_at":"2025-02-09T00:30:07Z","url":"https://github.com/dittofeed/dittofeed"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"powersnail"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"People are usually focused on how the payment model changed, but in fact, the products themselves have changed as well. Cloud storage and synchronizing data across multiple devices are now the norm, which incur continuous costs. And I think this is not something that's shoved into the customers' throat. Synchronization is indeed a valuable feature for many users.
Some of the subscriptions are certainly silly, like subscription for car features.
At least in the world of computers, I don't find too many products which are unjustifiably subscription-based. Subscriptions are usually paired with some form of synchronization/storage. And if you don't want cloud storage (or if you have your own cloud external to the application, or if you want to self host), there are usually non-subscription or even free options. Bitwarden, libreoffice, gimp, inkscape, etc.
So, I'd say as someone who's not currently into car purchase, I'm relatively content with the subscription models in the tech world. The services I subscribe to really do need continuous maintenance, and I've never been forced to subscribe to something that I think should not have been a subscription.
Adobe, though, has never been affordable to hobbyists in my opinion. Now, at least you can use it for a month and turn off the subscription."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Ask HN: Anyone tired of everything being a subscription now?"}},"_tags":["comment","author_powersnail","story_34041962"],"author":"powersnail","comment_text":"People are usually focused on how the payment model changed, but in fact, the products themselves have changed as well. Cloud storage and synchronizing data across multiple devices are now the norm, which incur continuous costs. And I think this is not something that's shoved into the customers' throat. Synchronization is indeed a valuable feature for many users.
Some of the subscriptions are certainly silly, like subscription for car features.
At least in the world of computers, I don't find too many products which are unjustifiably subscription-based. Subscriptions are usually paired with some form of synchronization/storage. And if you don't want cloud storage (or if you have your own cloud external to the application, or if you want to self host), there are usually non-subscription or even free options. Bitwarden, libreoffice, gimp, inkscape, etc.
So, I'd say as someone who's not currently into car purchase, I'm relatively content with the subscription models in the tech world. The services I subscribe to really do need continuous maintenance, and I've never been forced to subscribe to something that I think should not have been a subscription.
Adobe, though, has never been affordable to hobbyists in my opinion. Now, at least you can use it for a month and turn off the subscription.","created_at":"2022-12-18T22:00:14Z","created_at_i":1671400814,"objectID":"34044031","parent_id":34041962,"story_id":34041962,"story_title":"Ask HN: Anyone tired of everything being a subscription now?","updated_at":"2024-09-20T12:50:56Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"thanzex"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"This is absolute nonsense. \nBitwarden has worked absolutely perfectly for me until now, their clients work just fine and it's the password manager I always suggest to people around me.
I do both, self-host vaultwarden for a non-profit and have Bitwarden premium for personal use. A short while ago our server got nearly nuked and our Vaultwarden was down for several days, everyone in the org still could access all of our personal and shared passwords just fine, the extension and the clients stored all the necessary data offline and let us work uninterrupted until we restored the service ( ironically, it held the server's cloud provider credentials too ).
I suspect that in case of a complete outage or while not connected to the internet the client will work just fine, but on this instance something got messed up on the autentication/authorization side, so your client tried to authenticate to their server to sync up/do whatever it needs, since the server was not down but experiencing problems it received an error and logged you out.
I would argue this is by design, If the server returns an error while logging in there's probably a good reason, and especially in case of an organization account, you shouldn't have access to the passwords anymore.
You seem to have had major problems, but I assume it's likely your fault.\nYou should not store all the means of accessing an account in a single place, I too store TOTPs on Bitwarden, but that's just for convenience, I have them on my phone Authenticator app too. \nBut most importantly, as the name suggest, recovery codes ( which is what i assume your "temp verification passwords" are ) should be kept safe and in a separate place altogether, preferably printed even.
What you're describing here looks like nothing more than an outage, a thing that literally everyone and their dog experiences, from the non-profit like us to AWS, Microsoft, Google and Cloudflare.
Surely nothing to scream "Avoid at all costs" about."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["cost"],"value":"Bitwarden: Avoid at all costs (outage issue)"}},"_tags":["comment","author_thanzex","story_32782386"],"author":"thanzex","children":[32790410,32790679],"comment_text":"This is absolute nonsense. \nBitwarden has worked absolutely perfectly for me until now, their clients work just fine and it's the password manager I always suggest to people around me.
I do both, self-host vaultwarden for a non-profit and have Bitwarden premium for personal use. A short while ago our server got nearly nuked and our Vaultwarden was down for several days, everyone in the org still could access all of our personal and shared passwords just fine, the extension and the clients stored all the necessary data offline and let us work uninterrupted until we restored the service ( ironically, it held the server's cloud provider credentials too ).
I suspect that in case of a complete outage or while not connected to the internet the client will work just fine, but on this instance something got messed up on the autentication/authorization side, so your client tried to authenticate to their server to sync up/do whatever it needs, since the server was not down but experiencing problems it received an error and logged you out.
I would argue this is by design, If the server returns an error while logging in there's probably a good reason, and especially in case of an organization account, you shouldn't have access to the passwords anymore.
You seem to have had major problems, but I assume it's likely your fault.\nYou should not store all the means of accessing an account in a single place, I too store TOTPs on Bitwarden, but that's just for convenience, I have them on my phone Authenticator app too. \nBut most importantly, as the name suggest, recovery codes ( which is what i assume your "temp verification passwords" are ) should be kept safe and in a separate place altogether, preferably printed even.
What you're describing here looks like nothing more than an outage, a thing that literally everyone and their dog experiences, from the non-profit like us to AWS, Microsoft, Google and Cloudflare.
Surely nothing to scream "Avoid at all costs" about.","created_at":"2022-09-10T13:15:08Z","created_at_i":1662815708,"objectID":"32790317","parent_id":32782386,"story_id":32782386,"story_title":"Bitwarden: Avoid at all costs (outage issue)","updated_at":"2024-09-20T12:05:47Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"KronisLV"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"> Selfhost something like gitea with drone
I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions)
Edit: fixed the link now.
Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work.
> And then set up the users; Then set up the permissions; And move repos to it
Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole.
> And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features
The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup).
Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration.
> Then update the docs that describe how the repo structure works for onboarding
I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here.
> Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile.
It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below).
> And that's before any time lost to investigating and fixing outages, updating the software, and so on.
This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns.
That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons.
Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think.
Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...
Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Gitlab U-turns on deleting dormant projects after backlash"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/"}},"_tags":["comment","author_KronisLV","story_32350180"],"author":"KronisLV","comment_text":"> Selfhost something like gitea with drone
I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions)
Edit: fixed the link now.
Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work.
> And then set up the users; Then set up the permissions; And move repos to it
Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole.
> And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features
The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup).
Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration.
> Then update the docs that describe how the repo structure works for onboarding
I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here.
> Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile.
It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below).
> And that's before any time lost to investigating and fixing outages, updating the software, and so on.
This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns.
That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons.
Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think.
Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...
Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.","created_at":"2022-08-05T11:45:15Z","created_at_i":1659699915,"objectID":"32354739","parent_id":32352088,"story_id":32350180,"story_title":"Gitlab U-turns on deleting dormant projects after backlash","story_url":"https://www.theregister.com/2022/08/05/gitlab_reverses_deletion_policy/","updated_at":"2024-09-20T11:43:49Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"annoyingnoob"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"This looks really nice.
Atlassian did not consider small businesses with regulatory requirements when it decided to push everyone to the cloud. Atlassian's cloud cannot ever meet my regulatory requirements, by 2024 I need to replace Confluence. There is no way I can pay for the cost of the Data Center version of Confluence you'll be able to self-host, over $20K/year to self-host Confluence is a non-starter.
Does BookStack index uploaded files for search? If so, what formats does it support?
Can pages (or books) be exported in common formats?
Any plans to support Postgres in the future?"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: BookStack \u2013 An open source wiki platform and alternative to Confluence"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.bookstackapp.com/"}},"_tags":["comment","author_annoyingnoob","story_29851834"],"author":"annoyingnoob","children":[29853666],"comment_text":"This looks really nice.
Atlassian did not consider small businesses with regulatory requirements when it decided to push everyone to the cloud. Atlassian's cloud cannot ever meet my regulatory requirements, by 2024 I need to replace Confluence. There is no way I can pay for the cost of the Data Center version of Confluence you'll be able to self-host, over $20K/year to self-host Confluence is a non-starter.
Does BookStack index uploaded files for search? If so, what formats does it support?
Can pages (or books) be exported in common formats?
Any plans to support Postgres in the future?","created_at":"2022-01-08T17:03:50Z","created_at_i":1641661430,"objectID":"29853576","parent_id":29851834,"story_id":29851834,"story_title":"Show HN: BookStack \u2013 An open source wiki platform and alternative to Confluence","story_url":"https://www.bookstackapp.com/","updated_at":"2024-09-20T10:13:53Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"subarctic"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"Ok it may be just as painful and non-mainstream to self host these days as the pre-iphone or pre-blackberry smartphones were, and i can imagine that it could get easier in the future, but still what's the point of selfhosting for regular people when the cloud exists? Having a calendar, email/chat apps, webbrowser, maps+gps and everything else in your pocket was a major convenience improvement, but i don't see a benefit like that from self hosting. I only see better privacy, more control and ownership over your data, and in some cases lower cost (but often higher), and those aren't nearly as powerful motivators for people.
I could imagine self hosting becoming more accessible but don't see how it could become mainstream when it's just an alternative to stuff that's already available in the cloud"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The future is not self-hosted"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.drewlyton.com/story/the-future-is-not-self-hosted/"}},"_tags":["comment","author_subarctic","story_44682175"],"author":"subarctic","children":[44693065],"comment_text":"Ok it may be just as painful and non-mainstream to self host these days as the pre-iphone or pre-blackberry smartphones were, and i can imagine that it could get easier in the future, but still what's the point of selfhosting for regular people when the cloud exists? Having a calendar, email/chat apps, webbrowser, maps+gps and everything else in your pocket was a major convenience improvement, but i don't see a benefit like that from self hosting. I only see better privacy, more control and ownership over your data, and in some cases lower cost (but often higher), and those aren't nearly as powerful motivators for people.
I could imagine self hosting becoming more accessible but don't see how it could become mainstream when it's just an alternative to stuff that's already available in the cloud","created_at":"2025-07-25T17:10:44Z","created_at_i":1753463444,"objectID":"44685539","parent_id":44683238,"story_id":44682175,"story_title":"The future is not self-hosted","story_url":"https://www.drewlyton.com/story/the-future-is-not-self-hosted/","updated_at":"2025-07-27T16:43:28Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"Maro"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"Working at a non-tech regional bigco, where ofc cloud is the default, I see everyday how AWS costs get out of hand, it's a constant struggle just to keep costs flat. In our case, the reality is that NONE of our services require scalability, and the main upside of high uptime is nice primarily for my blood pressure.. we only really need uptime during business hours, nobody cares what happens at night when everybody is sleeping.
On the other hand, there's significant vendor lockin, complexity, etc. And I'm not really sure we actually end up with less people over time, headcount always expands over time, and there's always cool new projects like monitoring, observability, AI, etc.
My feeling is, if we rented 20-30 chunky machines and ran Linux on them, with k8s, we'd be 80% there. For specific things I'd still use AWS, like infinite S3 storage, or RDS instances for super-important data.
If I were to do a startup, I would almost certainly not base it off AWS (or other cloud), I'd do what I write above: run chunky servers on OVH (initially just 1-2), and use specific AWS services like S3 and RDS.
A bit unrelated to the above, but I'd also try to keep away from expensive SaaS like Jira, Slack, etc. I'd use the best self-hosted open source version, and be done with it. I'd try Gitea for git hosting, Mattermost for team chat, etc.
And actually, given the geo-political situation as an EU citizen, maybe I wouldn't even put my data on AWS at all and self-host that as well..."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["cloud"],"value":"Don't rent the cloud, own instead"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://blog.comma.ai/datacenter/"}},"_tags":["comment","author_Maro","story_46896146"],"author":"Maro","comment_text":"Working at a non-tech regional bigco, where ofc cloud is the default, I see everyday how AWS costs get out of hand, it's a constant struggle just to keep costs flat. In our case, the reality is that NONE of our services require scalability, and the main upside of high uptime is nice primarily for my blood pressure.. we only really need uptime during business hours, nobody cares what happens at night when everybody is sleeping.
On the other hand, there's significant vendor lockin, complexity, etc. And I'm not really sure we actually end up with less people over time, headcount always expands over time, and there's always cool new projects like monitoring, observability, AI, etc.
My feeling is, if we rented 20-30 chunky machines and ran Linux on them, with k8s, we'd be 80% there. For specific things I'd still use AWS, like infinite S3 storage, or RDS instances for super-important data.
If I were to do a startup, I would almost certainly not base it off AWS (or other cloud), I'd do what I write above: run chunky servers on OVH (initially just 1-2), and use specific AWS services like S3 and RDS.
A bit unrelated to the above, but I'd also try to keep away from expensive SaaS like Jira, Slack, etc. I'd use the best self-hosted open source version, and be done with it. I'd try Gitea for git hosting, Mattermost for team chat, etc.
And actually, given the geo-political situation as an EU citizen, maybe I wouldn't even put my data on AWS at all and self-host that as well...","created_at":"2026-02-05T11:00:29Z","created_at_i":1770289229,"objectID":"46898340","parent_id":46896146,"story_id":46896146,"story_title":"Don't rent the cloud, own instead","story_url":"https://blog.comma.ai/datacenter/","updated_at":"2026-03-05T23:32:15Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"avg_dev"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"That is really great context. I appreciate you taking the time to help me understand this all.
I'm going to bookmark your post so I have it now. This is all interesting and exciting to think about, and it makes me think of "Should I perhaps set up another VPS?" and "Should I look into becoming a website builder using some of these tools?" or maybe "Should I learn about the WP plugin ecosystem and consider becoming a plugin developer?" and many more. I do know from past experience though that going down any of these routes could turn into something that is quite time intensive and quite likely would not yield immediate results (and my time is, at the moment, mostly spoken for, and I have a full-time job). Still, it is definitely something I am thinking about, and I guess another thought that came about after reading your post was: "Wouldn't it be cool if there was a low-or-no-cost (low-cost most likely) way for non-tech-people to self-host things?" A sort of community anti-cloud VPS thing. Maybe run by some devops folks for very cheap, with the option of providing support and resiliency features at some cost. You just made me think: The idea of a small business or restaurant needing a low-touch website with the capability to self-update it is of course a very good one that makes total sense. And taking it a step further, wouldn't it be neat if stores could run their own online shopping sites without the need to pay someone like Shopify the large amount they do, and if restaurants could run their own delivery logistics without restoring to DoorDash, Uber Eats, or Skip the dishes? I guess I lean to the free open-source direction and envision a tech community that could keep wiki docs on how to self-host these things and the folks who ran them could update the docs as needed, and write code as needed, and so on. I don't know if what I'm saying is at all realistic; I just like a few things you have said, like Vanilla WP being one of the best things to happen to the web; I am guessing it just gives so many people the ability to have a nice website... I think it's a nice avenue of exploration and I am getting fed up with the centralization of all things web."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The WordPress 100 Year Plan"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://wordpress.com/100-year/"}},"_tags":["comment","author_avg_dev","story_37271764"],"author":"avg_dev","comment_text":"That is really great context. I appreciate you taking the time to help me understand this all.
I'm going to bookmark your post so I have it now. This is all interesting and exciting to think about, and it makes me think of "Should I perhaps set up another VPS?" and "Should I look into becoming a website builder using some of these tools?" or maybe "Should I learn about the WP plugin ecosystem and consider becoming a plugin developer?" and many more. I do know from past experience though that going down any of these routes could turn into something that is quite time intensive and quite likely would not yield immediate results (and my time is, at the moment, mostly spoken for, and I have a full-time job). Still, it is definitely something I am thinking about, and I guess another thought that came about after reading your post was: "Wouldn't it be cool if there was a low-or-no-cost (low-cost most likely) way for non-tech-people to self-host things?" A sort of community anti-cloud VPS thing. Maybe run by some devops folks for very cheap, with the option of providing support and resiliency features at some cost. You just made me think: The idea of a small business or restaurant needing a low-touch website with the capability to self-update it is of course a very good one that makes total sense. And taking it a step further, wouldn't it be neat if stores could run their own online shopping sites without the need to pay someone like Shopify the large amount they do, and if restaurants could run their own delivery logistics without restoring to DoorDash, Uber Eats, or Skip the dishes? I guess I lean to the free open-source direction and envision a tech community that could keep wiki docs on how to self-host these things and the folks who ran them could update the docs as needed, and write code as needed, and so on. I don't know if what I'm saying is at all realistic; I just like a few things you have said, like Vanilla WP being one of the best things to happen to the web; I am guessing it just gives so many people the ability to have a nice website... I think it's a nice avenue of exploration and I am getting fed up with the centralization of all things web.","created_at":"2023-08-28T03:05:37Z","created_at_i":1693191937,"objectID":"37289237","parent_id":37283910,"story_id":37271764,"story_title":"The WordPress 100 Year Plan","story_url":"https://wordpress.com/100-year/","updated_at":"2024-09-20T15:04:25Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"Zante"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"TLDR: got tired of my desk, so now I touch grass while coding from my watch.
Ever since the 2021 GH Copilot beta saved me from dual carpal tunnel, I figured AI's main benefit in coding would be cutting typing while keeping productivity. That's turned out true; no one writes their own code lately. Why wouldn\u2019t you have AI do the first draft? Why not your updates too? I expected phone coding to rise next, but tiny keyboards wreck your hands even faster. To put this into practice, I started leaving my Windows desktop on 24/7 and SSHing in from my phone, yet the problem just transformed: now I had finger pain typing long prompts to Claude Code.
I also commute 2 hours a day between SF and PayPal HQ, where I work as an AI Specialist / Sr SWE overseeing our AI coding-agent tooling. During that commute I couldn't touch my machine's work at all. So the app was initially just voice-activated coding for CarPlay, so I could dispatch and talk to agents entirely by voice while driving, like TTS texting.
While building it, a friend told me about his older brother, who dispatches Claude Code by voice with a lav mic on his collar. Looks a bit strange, but you can instantly see how it works: he walks around outside and voice codes. That's when it clicked that I could do a native watchOS app. I'd owned an Apple Watch for years and barely used it; it's now my favorite use case.
How it works: you speak from your watch, phone, or CarPlay, and the app opens SSH sessions into your own machines (any number), where your coding agent of choice runs. A go-between agent interprets what you say, dispatches the work, and reads results back when done. It has context compression and message queuing so you can keep talking while sessions run.
Backend: two options. Use my cloud service for chat history/configs, or self-host. The backend is a Java Spring Boot app shipping as a single executable JAR with an embedded web server and H2 database, so you just need Java 21. No separate database to configure; it creates its data file under ~/.dashvox on first run. You don't need an account, and your code could avoid leaving your machine. Self-hosting also supports VPNs like Tailscale between phone and machine, which is how I run mine.
The only thing that always touches my cloud is push notifications. APNs requires an auth key that must stay server-side, so the backend holds it; your device registers its APNs token on open so it knows where to deliver. That's the only data routing through me; your sessions and code don't.
Cost: the app is free and I want to keep it that way. COGS are near zero since you bring your own machines and keys, so you only pay your existing providers. There's an optional donations page in settings; at most I'd add a small one-time purchase someday, never a subscription. You connect your machines, an LLM API key (~$25-50 lasts a while), and optionally a Twilio key for texting; the go-between offloads most work to your coding CLI.
I tried configuring Siri, but Siri is honestly terrible, so I added Twilio: you can text the agent through Messages (already Siri-native).
It's built for technical users. I\u2019d steer non technical users to regular coding agents first; the value only lands once you're already paying for one, sick of waiting at your desk, and want outside. So this is for engineers and founders.
The link is above; feedback and suggestions welcome. iOS is about as far as I can take it (iPhone / Watch / CarPlay). Next I'm exploring Meta glasses, though their voice API is restrictive. Android is nearly done (I built it first, I'm mainly a Java dev), but the Play Store needs 12 beta testers and I'm not sure I know that many Android users; if you'd want to be one, reach out.
Ultimately I just want people to get outside more without choosing between that and shipping their own work. I haven't found anything else that does quite this, and it's hands down the best way I've found to remotely control a computer."},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Voice control coding agents on your machine via smartwatch / CarPlay"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://dashvox.ai"}},"_tags":["story","author_Zante","story_48356768","show_hn"],"author":"Zante","children":[48356815,48361265,48371184,48436945],"created_at":"2026-06-01T13:41:49Z","created_at_i":1780321309,"num_comments":0,"objectID":"48356768","points":7,"story_id":48356768,"story_text":"TLDR: got tired of my desk, so now I touch grass while coding from my watch.
Ever since the 2021 GH Copilot beta saved me from dual carpal tunnel, I figured AI's main benefit in coding would be cutting typing while keeping productivity. That's turned out true; no one writes their own code lately. Why wouldn\u2019t you have AI do the first draft? Why not your updates too? I expected phone coding to rise next, but tiny keyboards wreck your hands even faster. To put this into practice, I started leaving my Windows desktop on 24/7 and SSHing in from my phone, yet the problem just transformed: now I had finger pain typing long prompts to Claude Code.
I also commute 2 hours a day between SF and PayPal HQ, where I work as an AI Specialist / Sr SWE overseeing our AI coding-agent tooling. During that commute I couldn't touch my machine's work at all. So the app was initially just voice-activated coding for CarPlay, so I could dispatch and talk to agents entirely by voice while driving, like TTS texting.
While building it, a friend told me about his older brother, who dispatches Claude Code by voice with a lav mic on his collar. Looks a bit strange, but you can instantly see how it works: he walks around outside and voice codes. That's when it clicked that I could do a native watchOS app. I'd owned an Apple Watch for years and barely used it; it's now my favorite use case.
How it works: you speak from your watch, phone, or CarPlay, and the app opens SSH sessions into your own machines (any number), where your coding agent of choice runs. A go-between agent interprets what you say, dispatches the work, and reads results back when done. It has context compression and message queuing so you can keep talking while sessions run.
Backend: two options. Use my cloud service for chat history/configs, or self-host. The backend is a Java Spring Boot app shipping as a single executable JAR with an embedded web server and H2 database, so you just need Java 21. No separate database to configure; it creates its data file under ~/.dashvox on first run. You don't need an account, and your code could avoid leaving your machine. Self-hosting also supports VPNs like Tailscale between phone and machine, which is how I run mine.
The only thing that always touches my cloud is push notifications. APNs requires an auth key that must stay server-side, so the backend holds it; your device registers its APNs token on open so it knows where to deliver. That's the only data routing through me; your sessions and code don't.
Cost: the app is free and I want to keep it that way. COGS are near zero since you bring your own machines and keys, so you only pay your existing providers. There's an optional donations page in settings; at most I'd add a small one-time purchase someday, never a subscription. You connect your machines, an LLM API key (~$25-50 lasts a while), and optionally a Twilio key for texting; the go-between offloads most work to your coding CLI.
I tried configuring Siri, but Siri is honestly terrible, so I added Twilio: you can text the agent through Messages (already Siri-native).
It's built for technical users. I\u2019d steer non technical users to regular coding agents first; the value only lands once you're already paying for one, sick of waiting at your desk, and want outside. So this is for engineers and founders.
The link is above; feedback and suggestions welcome. iOS is about as far as I can take it (iPhone / Watch / CarPlay). Next I'm exploring Meta glasses, though their voice API is restrictive. Android is nearly done (I built it first, I'm mainly a Java dev), but the Play Store needs 12 beta testers and I'm not sure I know that many Android users; if you'd want to be one, reach out.
Ultimately I just want people to get outside more without choosing between that and shipping their own work. I haven't found anything else that does quite this, and it's hands down the best way I've found to remotely control a computer.","title":"Show HN: Voice control coding agents on your machine via smartwatch / CarPlay","updated_at":"2026-06-08T20:38:04Z","url":"https://dashvox.ai"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"felipejfc"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":"Hey HN,
I built EZClaw (https://www.ezclaw.app) to solve a problem I kept running into: non-technical friends and family wanted their own AI assistant, but the setup barrier was too high. Self-hosting means Docker, API keys, cloud accounts, SSH \u2014 none of that is reasonable to ask of normal people.
EZClaw is managed hosting for OpenClaw (https://github.com/openclaw), an open-source personal AI assistant that lives in Telegram. You sign up, connect your Telegram, pick an AI model through OpenRouter (or use your openai/anthropic api key), and you're done. No cloud accounts, no API keys to manage, no servers to maintain.
What you get:\n- A personal AI assistant in Telegram that can search the web, manage files, run code, control smart home devices, and more\n- Choice of AI model (Claude, GPT-4, Gemini, Llama, etc.) via OpenRouter \u2014 you can bring your own OpenRouter/OpenAI/Anthropic key so you control model costs separately -- or rely solely on managed solution\n- Each user gets their own isolated container\n- The assistant remembers context across conversations
How it works technically: each user gets a dedicated OpenClaw instance running in a container. OpenClaw itself is an agent runtime \u2014 it connects to Telegram as your bot, routes to your chosen LLM via OpenRouter, and has a plugin system for tools (web search, browser automation, home assistant, etc.). EZClaw just handles the infra: provisioning, updates, monitoring, backups.
Pricing: $0.05/hr for the hosting. AI model costs are separate and go either through our openrouter infra or your OpenRouter/Anthropic/OpenAI account, so you have full visibility and control over that spend.
The underlying OpenClaw project is open source, so you can always self-host if you prefer. EZClaw is for people who'd rather not deal with that.
I'd love feedback on the product, pricing, or the approach in general. Happy to answer questions about the architecture."},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: EZClaw \u2013 Deploy OpenClaw agents in \u2013 1 minute \u2013 no tech skills needed"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://ezclaw.app"}},"_tags":["story","author_felipejfc","story_46966355","show_hn"],"author":"felipejfc","children":[46986151],"created_at":"2026-02-10T20:26:19Z","created_at_i":1770755179,"num_comments":0,"objectID":"46966355","points":2,"story_id":46966355,"story_text":"Hey HN,
I built EZClaw (https://www.ezclaw.app) to solve a problem I kept running into: non-technical friends and family wanted their own AI assistant, but the setup barrier was too high. Self-hosting means Docker, API keys, cloud accounts, SSH \u2014 none of that is reasonable to ask of normal people.
EZClaw is managed hosting for OpenClaw (https://github.com/openclaw), an open-source personal AI assistant that lives in Telegram. You sign up, connect your Telegram, pick an AI model through OpenRouter (or use your openai/anthropic api key), and you're done. No cloud accounts, no API keys to manage, no servers to maintain.
What you get:\n- A personal AI assistant in Telegram that can search the web, manage files, run code, control smart home devices, and more\n- Choice of AI model (Claude, GPT-4, Gemini, Llama, etc.) via OpenRouter \u2014 you can bring your own OpenRouter/OpenAI/Anthropic key so you control model costs separately -- or rely solely on managed solution\n- Each user gets their own isolated container\n- The assistant remembers context across conversations
How it works technically: each user gets a dedicated OpenClaw instance running in a container. OpenClaw itself is an agent runtime \u2014 it connects to Telegram as your bot, routes to your chosen LLM via OpenRouter, and has a plugin system for tools (web search, browser automation, home assistant, etc.). EZClaw just handles the infra: provisioning, updates, monitoring, backups.
Pricing: $0.05/hr for the hosting. AI model costs are separate and go either through our openrouter infra or your OpenRouter/Anthropic/OpenAI account, so you have full visibility and control over that spend.
The underlying OpenClaw project is open source, so you can always self-host if you prefer. EZClaw is for people who'd rather not deal with that.
I'd love feedback on the product, pricing, or the approach in general. Happy to answer questions about the architecture.","title":"Show HN: EZClaw \u2013 Deploy OpenClaw agents in \u2013 1 minute \u2013 no tech skills needed","updated_at":"2026-03-05T23:34:17Z","url":"https://ezclaw.app"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"jasode"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["self","host","n8n","cloud","cost"],"value":">As the fortunes of AWS et al rose and rose and rose, I kept looking at their pricing at features and kept wondering what I was missing. They seemed orders of magnitude more expensive [...] To this day I still use bare metal servers for pretty much everything, [...] plain Linux, Bash, Perl, Python, and SSH, to handle everything cheaply
Your FastMail use case of (relatively) predictable server workload and product roadmap combined with agile Linux admins who are motivated to use close-to-bare-metal tools isn't an optimal cost fit for AWS. You're not missing anything and FastMail would have been overpaying for cloud.
Where AWS/GCP/Azure shine is organizations that need higher-level PaaS like managed DynamoDB, RedShift, SQS, etc that run on top of bare metal. Most non-tech companies with internal IT departments cannot create/operate "internal cloud services" that's on par with AWS.[1] Some companies like Facebook and Walmart can run internal IT departments with advanced capabilities like AWS but most non-tech companies can't. This means paying AWS' fat profit margins can actually be cheaper than paying internal IT salaries to "reinvent AWS badly" by installing MySQL, Kafka, etc on bare metal Linux. E.g. Netflix had their own datacenters in 2008 but a 3-day database outage that stopped them from shipping DVDs was one of the reasons they quit running their datacenters and migrated to AWS.[2] Their complex workload isn't a good fit for bare-metal Linux and bash scripts; Netflix uses a ton of high-level PaaS managed services from AWS.
If bare metal is the layer of abstraction the IT & dev departments are comfortable working at, then self-host on-premise, or co-lo, or Hetzner are all cheaper than AWS.
[1] https://web.archive.org/web/20160319022029/https://www.compu...
[2] https://media.netflix.com/en/company-blog/completing-the-net..."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Why we use our own hardware"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.fastmail.com/blog/why-we-use-our-own-hardware/"}},"_tags":["comment","author_jasode","story_42485124"],"author":"jasode","children":[42516060],"comment_text":">As the fortunes of AWS et al rose and rose and rose, I kept looking at their pricing at features and kept wondering what I was missing. They seemed orders of magnitude more expensive [...] To this day I still use bare metal servers for pretty much everything, [...] plain Linux, Bash, Perl, Python, and SSH, to handle everything cheaply
Your FastMail use case of (relatively) predictable server workload and product roadmap combined with agile Linux admins who are motivated to use close-to-bare-metal tools isn't an optimal cost fit for AWS. You're not missing anything and FastMail would have been overpaying for cloud.
Where AWS/GCP/Azure shine is organizations that need higher-level PaaS like managed DynamoDB, RedShift, SQS, etc that run on top of bare metal. Most non-tech companies with internal IT departments cannot create/operate "internal cloud services" that's on par with AWS.[1] Some companies like Facebook and Walmart can run internal IT departments with advanced capabilities like AWS but most non-tech companies can't. This means paying AWS' fat profit margins can actually be cheaper than paying internal IT salaries to "reinvent AWS badly" by installing MySQL, Kafka, etc on bare metal Linux. E.g. Netflix had their own datacenters in 2008 but a 3-day database outage that stopped them from shipping DVDs was one of the reasons they quit running their datacenters and migrated to AWS.[2] Their complex workload isn't a good fit for bare-metal Linux and bash scripts; Netflix uses a ton of high-level PaaS managed services from AWS.
If bare metal is the layer of abstraction the IT & dev departments are comfortable working at, then self-host on-premise, or co-lo, or Hetzner are all cheaper than AWS.
[1] https://web.archive.org/web/20160319022029/https://www.compu...
[2] https://media.netflix.com/en/company-blog/completing-the-net...","created_at":"2024-12-22T20:56:35Z","created_at_i":1734900995,"objectID":"42489018","parent_id":42488447,"story_id":42485124,"story_title":"Why we use our own hardware","story_url":"https://www.fastmail.com/blog/why-we-use-our-own-hardware/","updated_at":"2025-01-07T19:09:43Z"}],"hitsPerPage":20,"nbHits":13,"nbPages":1,"page":0,"params":"query=self-host+n8n+cloud+cost&advancedSyntax=true&analyticsTags=backend","processingTimeMS":26,"processingTimingsMS":{"_request":{"roundTrip":28},"afterFetch":{"format":{"highlighting":2,"total":2},"merge":{"mergeLoop":{"prepareNextHit":1,"total":1},"total":2},"total":2},"fetch":{"query":7,"scanning":15,"total":23},"total":26},"query":"self-host n8n cloud cost","serverTimeMS":29}