Agreed, the instructions could use an adjustment. It seems odd the data part would no longer work.
Longer downtime every year or so is not so bad…
Nope, no problems except for the ones I created by my errant editing of web_only.yml with existing app.yml config. 
Happy to report this now seems to be working for this two container setup!
The only issue that remains is the site text used for telling you how to rebuild from cli (“app”) but that’s a very small thing.
cc: @pfaffman
yeah. that’s hard-coded. If you can’t remember you’ll need to customize the text. 
5 posts were split to a new topic: Build fails due to ruby version mismatch
That can never work. Sorry I missed that before. I updated the OP. If you need to rebuild data, then you need to
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
No. That’s exactly what is expected. You can’t rebuild postgres while another postgres is accessing the files. If a new data container is created you need to destroy and start a new web_only container because docker somehow links to the exact container rather than some reference to the one named data.
Thanks for the OP edits 
and help in Build fails due to ruby version mismatch
Am I going crazy or does the discourse-install script no longer contain a –two-container argument? I ran it straight from the recommended location (https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse) in a fresh Ubuntu 24.04 VPS on Hetzner and it just installed a regular one container setup with an app.yml. I thought maybe I need to run the discourse-setup one that comes out of it, but that just did the same thing again.
Use the manual install method and ./discourse-setup --two-container Worked fine for me last time I used it.
Or install using the nifty install script then convert to two containers as referenced in OP
@Falco and @pmusaraj Do you think it would be handy if parts of the old INSTALL-cloud.md were kept handy somewhere and referenced in the current INSTALL-cloud.md
It was indeed removed, I removed the reference from the wiki above.
Thanks for the info. Why was it removed? It was a very handy method.
Two containers installs made by people who aren’t deeply familiar with Docker generated far too much support burden. It’s an advanced install setup, that should be reserved for people who know their way around.
So you are making it difficult for those of us using that feature. Did you ask anyone about the change in advance? Seems you could have left it in place given one can use the OP method incorrectly and still create some issues for themselves.
Burden for whom? In this thread? The support has been provided by volunteers/users, not so much by Team.
So you’ll leave the web_only and data in samples and people who want to use two containers will have to copy and configure them by hand? The only extra support it required before was helping people who never bothered to update the data container.
Now we’ll need to tell a bunch of people how to use cp and nano. Arguably, if you don’t know cp and nano, you shouldn’t run a two-container setup. Jeff argued that if you don’t know cp and nano then you shouldn’t install Discourse, but I managed to change his mind when I wrote discourse-setup.
in the next while I’ll re-write my dashboard.literatecomputing.com to stop doing standard installs (since it can’t pipe answers into discourse-setup anymore) and will continue to make a 2-container install an option there.
I’m not a fan. This feels like one step closer to dropping support for two-containers overall and that would be a huge shame.
And that is what is great about open source; people have the choice to pick their own adventure!
Dozens of people running outdated containers completely forgotten is not great and caused much confusion every time PostgreSQL needed a major update, which in turn made our PostgreSQL happen less often, making the overall product worse.
I agree 
It is not possible to really drop support for two (or N) container installs; Discourse natively connects to external databases, like documented in Configure Discourse to use a separate PostgreSQL server.
No flexibility was removed, but analogous to The Power of Defaults, every option in tooling we create becomes something that needs to be accounted for.
Removing thousands of script lines and streamlining the installer to cover the vast more common use case was a conscious choice, but Discourse still supports all the same use cases, and people are free to venture their own path if they choose to.
Thanks for the reassurance that this mode of production will continue to work without significant levels of customisation 
Convenience for those of using the removed method was sacrificed in favor of forcing a path on everyone. Was this a decision by one or were others involved?
From codinghorror
"Defaults are arguably the most important design decisions you’ll ever make as a software developer. Choose good defaults, and users will sing the praises of your software and how easy it is to use. Choose poor defaults, and you’ll face down user angst over configuration, and probably a host of tech support calls as well."
IMHO poor defaults have been chosen and the choice/change was done without involvement, discussion, or consideration with the class of users lamenting the change.
Asking again, a conscious choice by whom?
This user experiences that comment as arrogance and disrespect. It feels like one might feel if they are looked down upon and disregarded. I doubt the intent was to cause such a reaction but here we are.
Overall, this episode is consistent of what I was complaining of in a PM with @nat a few weeks back. CDCK/Meta has two unequal classes of customers, the ones that pay for hosting and the folks that self host. The approach in this episode is latest and perhaps most egregious example of this two class system.
With all that said…
I applaud the new installer. Is does a nice job of dealing with installation issues and the resulting support demands going back to day one.
As for the change, CDCK has the right to build/change as they see fit. No argument there. My hope is they can do so in a way that does not alienate folks.
Lastly, the rereading of the post by codinghorror got me thinking about how things often were when Jeff got involved in a post. His posts often smacked of disregard, disrespect, and mild arrogance. Fortunately I was never the direct focus of that but some of those post were painful to read. My recent interaction with staff around how a post was handled and this episode feel very similar. Maybe it is just me.
That seems a bit harsh. The team helps self-hosters everyday on this forum, even those who fall into unsupported-install 