Contabo experience with Plesk, Webmin or other server-admin setup?

Hey guys! Can someone comment about experience and gotchas of hosting with
They seem very affordable, but have a pretty “old-school” admin panel and offer to install Plesk or Webmin.

Does it even make sense to install such tools (if I’m not going to host apps like Wordpress or resell hosting on the same machine)?

What are the benefits and downsides of using Plesk or Webmin or some other admin tool on the server dedicated for Discourse instance?

What is the recommended and sufficient set of tools to install for monitoring and maintenance of a Discourse-only machine?

I’m new to such tools and will appreciate any advice on good server management and monitoring practices.

EDIT: I reviewed the following topics, but still your input to questions above is very appreciated.

Your life will be much easier if you don’t try to work with such tools. It’s possible, but if you’re not going to use them to continue to change your configuration they bring nothing to the party.

I’ve written most of a rails app that will install Discourse, but have been too busy working to get it finished

Usually upgrades can be done from Discourse’s web interface,though sometimes running a command from a shell is required. Monitoring did you can do with whatever tools the hosting service provides (digital ocean has some pretty graphs) or use a third party service.


Thanks, @pfaffman! I see, folks at CDCK use both Prometheus and Pingdom (which can get quite pricey).

Can someone point me to a post/article about running a large Discourse forum with a balanced view on using paid & FOSS tools for monitoring and tuning the performance?

For the most part, people with experience driving large forums are too busy running them to write much about it.

Mostly, you need ram and fast cpu and ssd.

What does large mean? How many users, posts, page views?

Makes sense :slight_smile:
Let’s consider a forum as pretty large with 50k-100k monthly active users generating around 1 mil. pageviews/mo. (and suppose the traffic is steady, i.e. no significant frequent spikes).

What could be the roughly sufficient figures for RAM & CPU?
And what would be a fairly sane setup in terms of monitoring, security and performance management?

I understand there are many variables, approaches and caveats here, but hopefully folks can share their experiences in the scope of running Discourse-based forums.

The number of posts and users in your database is an indicator of how big the database is. You don’t include that, so this is still a guess.

I’ve got a couple forums about like that. One’s on a Digital Ocean 8GB droplet. The other is on a 12GB High CPU instance.

I’d recommend separate data and web containers. You may want to tweak the mem settings for the database and number of unicorn workers.

1 Like

Thanks, that’s pretty interesting! Any chance you could share your experiences in a tutorial or here, especially how to tweak the settings for mem and unicorns, based on your examples?

Does it make sense to have separate containers (for data and web app) on the same VPS machine?
Can you elaborate on such setup as to 5 yr old?
What gains and caveats are there with such setup?

1 Like

There are comments in the config files with suggestions.

Yes. See Multisite configuration with Docker

I’ve worked hard to see that discourse-setup will work for a 5 year old and it works pretty well for lots of people. It’s not really reasonable to expect a 5 year old to be able to manage a site with a million page views per month.


Hmm… I reviewed the linked thread and seems like since 2014 the multi-core and multi-container setup is still quite questionable (pains vs. gains) and very use-case dependent. Thanks anyway, I’ll keep it simple. :slight_smile:

Just to clarify: Multisite is something different then separating the web and database containers.

  • Separating web and database containers allows you to run both containers on different machines and to shorten the rebuild time (by creating a new web container and migrating the database in the background while the old web container is still running).
  • Multisite is about hosting many sites on the same machine. You could do this by running multiple containers, but then the RAM requirements would scale linearly with the number of sites you host. With multisite, multiple sites are served by the same container, so resource consumption for many small sites will be just as much as for one large site with the same size and activity (plus for a tiny overhead per site) :slight_smile:

I’ve personally avoided a multi-container setup (because I don’t care about a few minutes of downtime on the occasional rebuild), but am using multisite (because I’m hosting more sites an a single machine than the host has gigabytes of RAM :wink:).


It’s a real bummer to have your site down for 2-10 minutes (depending on number of plugins and network and CPU speed) to add a plugin or do a rebuild to upgrade when it’s required. Once a two-container configuration is set up, it’s pretty much the same as a one-container setup except that you can rebuild your web server while the old one continues to work.

1 Like

Note that since then I moved back to multisite and multi-containers, with no problem on upgrades.