Crossed 50k pageviews per month on Discourse

The good news is that usage of this forum is slowly but steadily rising. For the first time passed the 50k page views per month (51.3k). The bad news is that our open source free Discourse hosting officially only allows 50k page views per month. They claim they will only start complaining when this limit is exceeded continuously for some time, so no worry and no hurry. Still

  • My conclusion is that Discourse is a big step ahead in creating a forum with good discussions that acts as a useful resources, notably thanks to the frequent involvement of @EricGT.
  • If we get kicked out of the free plan we have two options, both of which have the nice side effect that some limitations on using plugins are lifted
    • Self hosting
    • Paid plan

So, again, without worry or hurry, is some (commercial) user willing to solve this? Solving means either paying a plan hosted by Discourse (in return there can be a sponsored by banner) or getting a self hosted solution organized and maintained. I guess the first is the simplest option.

2 Likes

Some additional info:

Paid plan:
Discourse pricing plans

Self hosting:
How Do I Install Discourse?

Third option - self-supported community install
Another option since Discourse is open source (GitHub) and free is to pay a third party to do the site install and regular upgrades. There are down sides to this and the only knowledge I have of this is reading some of the Discourse forum post, e.g. Hosting options (Discourse hosting vs. 3rd party hosting). IIRC there are more 3rd party support providers than just the two in the links noted in this option.

My reply is not an endorsement of any specific one of these options but just something to help those in needing more information. Also while I don’t mind doing the odd admin chores for this site, if this site is self hosted please don’t take that to mean I would be willing to extend the help to doing the install, upgrades and restarts. I am not opposed to assisting others with that but my server admin skills are decades old.

EDIT

For those who are also thinking this might work on a Raspberry Pi 4 it will not but maybe Raspberry Pi 5 when it arrives in a few years.

3 Likes

Right, but how about a Beowulf cluster of Raspberry Pies?

I don’t know I have not tried this; also Ruby on Rails and such is something I have never used. My best advise would be to jump in on the discussion at the Discourse forum and ask there.

I ran some Discourse instances a number of years ago
it was relatively straight-forward to set up, but obviously it would require some active attention, backups, and the like.

2 Likes

As long as doing it is idiot proof and takes no more than about 15 minutes a week I don’t mind. I know Jan does backups every few weeks and the updates from Discourse are noted as being a one click operation, but if a problem should occur with the Ruby-on-Rails code or such then I am not the one to call.

Also from reading it appears that Discourse only prefers self-hosting being done as Docker containers which I have some experience with, but not much.

Yeah
it’s the Docker stuff that makes me a little leery. I personally find it makes things really challenging to debug when they go wrong.

If you’d be okay with managing it though, I would be happy to assist if needed; I have some experience with both sysadmin-type stuff and Rails itself.

It seems between the two of us we have 2/3 of what is needed covered but the 1/3 we are missing is what to do when critical bug aborts a system or server. I don’t know if rolling a Docker instance back to the last safe docker instance will preserve the new post (data) since the change.

Yes
I’ve set things up for my own work with rolling PostgreSQL backups, but that’s a solution with a bunch of moving parts as well & restoring isn’t a simple process.

1 Like

Just reading a few post on Discourse meta (How to recover my broken (not web-accessible) Discourse installation after failed upgrade), the impression I am getting for dealing with potential upgrade failures is to

  1. Use multiple virtual Discourse servers so that one can host the site live while another Discourse server is being upgraded.
  2. Use a separate physical database server.
  3. When one of the Discourse serves is upgraded and working then just redirect to it and if the upgraded Discourse server works correctly for a time, upgrade the remaining server.

Seems that by having a separate database server the Discourse servers can be upgraded and possibly downgraded without needing to touch the database as long as the Discourse upgrade did not do a breaking change. When hosting with Discourse the company, backups are done every 12 hours.

Do I sense you two want to try self hosting? That also means we need a machine at some reliable place. Possibly @anniepoo can help out at Oregon?

I am not opposed to it .

If a Discourse plan is used the obvious pricing plan to use would be the Standard plan. (ref)

The Pros of using self-hosting vs the Discourse standard pricing plan:

  1. I believe it will be cheaper in the long run. Standard plan is $100/month. (ref), however we are eligible for 50% off thus $50/month. (ref) The upfront cost for self-hosting is obviously higher to acquire the hardware.
  2. The limits such as number of users, page views, and memory would only be set by the machine limits. With the standard plan the pageviews are limited to 100k monthly page views which I would expect this site would reach in a few years and the next plan up is the business plan at $300/month. :grimacing: (ref)
  3. @jamesnvc has some experience from a number of years ago with maintaining Discourse. (ref)
  4. The Discourse forum is active and many of the 3rd-party service providers are active there. It is not uncommon to get a response to a system problem from a few minutes to a few hours. Both Discourse employees and 3rd-party service providers will offer simple free advise and are willing to do more involved support for a fee which is expected. Discourse Forum - Category: Marketplace (ref 1).
  5. We can use more of the plugins. The Standard plan does not allow for many additional plugins. (ref)
  6. We can write custom plugins if needed which AFAIK can only be done with Ruby-on-Rails. (ref)
  7. It would interesting to see if parts of the site could be migrated to using SWI-Prolog.
  8. @anniepoo might be able to make effective use of the site with her training. (ref)
  9. Might be able to have tighter integration with SWISH and the SWI-Prolog documentation.
  10. If the site keeps growing, which I have no reason to believe it would not, then eventually it will reach a point were paying for a Discourse plan is out of the possibilities and the site would have to move to self-hosting. (ref)
  11. Most Discourse customers are not as computer literate as the users on this site. This site definitely has some of the most computer literate users of any Discourse site (ref 1) (ref 2) (ref 3), so that is a big plus in our favor.
  12. With all of the software being open-source and free there is no reason we cannot setup a trial system running in parallel (different URL obviously) for a while to learn during this window of opportunity. (ref)
  13. We can pick the version of Discourse to run, e.g. (Stable, tests-passed, Git branch tip, etc.). Since we typically don’t even need the latest stable, we can wait a week or so to see if any problems were noted on the Discourse forum of problems, e.g. PostgreSQL 12 update (ref). Some of the problems I see with these are when plug-ins don’t work with the release.
  14. We can import the old mailing list messages. (Google Groups)

The Cons of using self-hosting:

  1. AFAIK none of us have any experience in dealing with critical bugs with Discourse.
  2. AFAIK none of us have any current experience in maintaining Discourse.
  3. The toolchain is different; Ruby 2.6+, PostgreSQL 10+, Redis 4.0+, Ember.js (ref 1) (ref 2)
  4. We don’t get the security patches by default and would have to install them. Also I suspect that when the security holes are found, patched and released, we would be getting the security notification at the same time as everyone; not a good option in the world of security patching. (ref)
  5. We would have to test each release before moving it into production which would mean keeping more than one set of sites on the hardware. Discourse currently updates our site a few times a month. Discourse releases stable version every few moths (ref) and tests-passed (ref) occurs every few days, so to stay up with the latest release would be some effort. Related: How do I manually update Discourse and Docker image to latest?
  6. We would have to get a CDN if needed. (ref 1) (ref 2)
  7. Response times with Discourse hosting are considerably higher than cloud environments due to lack of virtualization which has a particularly bad penalty on Ruby applications. (ref)
  8. Need an SMTP server (ref 1) (ref 2)
  9. Need hostname (ref 1) (ref 2)

As the self-hosting is typically done on Docker, the pros and cons of Docker also apply, but I have no experience with Docker in a production system so can’t elaborate them. I have used Docker with Neo4j on my local machine to get started but during development with Neo4j moved to a local install of Neo4j because it made development much easier and faster.

I also have no hard facts on how many sites use Discourse without a Discourse plan or 3rd-party support and what is their up-time statistics.

Discourse also has a separate category for system admins that has how-to guides and is responsive.


There is no reason any of us can not pull down all of the needed software and do an install. As this is done with Docker I see no reason it can not be done on a laptop as a learning exercise. (ref) I plan to try this but don’t have a time frame. Lastly a backup of this site can be installed on to the system.


Personal notes

Discourse - Forum

Faster rebuilds?
How to move from standalone container to separate web and data containers
HOWTO: Build yourself a sandbox
Update error, website unavailable, possibly plugin related?
How to use Docker multiple containers without exposing ports
Linking containers for a multiple container setup
Running Discourse with a separate PostgreSQL server
Two-factor login on staging site
Best Practices for Backups

Statement: (ref)
5 min of downtime every month is still like 99,5% uptime so unless the two container install is easy to do/manage it doesn’t worth it


Response:
For a description see: How to move from standalone container to separate web and data containers .

For a normal rebuild/upgrade It’s pretty much the same as a single container install. Rather than

./launcher rebuild app

you do

./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start w

Statement: it’s stuck on “currently upgrading” its been like it for a while. (ref)

Response:
SSH in and issue a launcher rebuild app

Statement by Rafael dos Santos Silva Falcoteam (Dated: 09-09-2019) (ref)
We provide standard ways to connect to databases outside the application container, like Running Discourse with a separate PostgreSQL server . The details of networking on those advanced setups are up to you, since it will be wildly different depending on your implementation.

We already gives a dead simple install for everyone on discourse/INSTALL-cloud.md at master · discourse/discourse · GitHub that works and power thousands of instances in the internet. I’m afraid that those who opt into following their own path will have to deal with the consequences as it is impossible for us to provide support for all the possible combinations.

Digital Ocean - Discourse Droplet (ref)

You really want at least 20gb and you really want ssd. (ref)
if You’re using the Ubuntu 16.04 or Higher, Your system can automagically update docker when an update is available. (ref)

Improve my DO (Digital Ocean) droplet setup

There are several folders involved in a typical Discourse install (ref)
/var/discourse and all the directories below it are the only place we store persistent data. (ref)


Discourse Forum administrator tutorials (ref)

Export User Information List - List does not contain method of login such as Google, Twitter, GitHub, etc. which would be nice to know.
Move your Discourse Instance to a Different Server
How do I manually update Discourse and Docker image to latest?
Configuring Google login for Discourse
Configuring Facebook login for Discourse
Configuring Twitter login (and rich embeds) for Discourse
How to use Auth0 with the OAuth2 Basic Plugin
Configuring GitHub login for Discourse
Configuring OneLogin’s SAML for Discourse
Configuring authentication checks on incoming email
Restore a backup from command line - This is handy when you’re moving servers.
Full site CDN acceleration for Discourse
What to do when you have locked yourself out by invalid SSO configuration or read-only mode
Enable a CDN for your Discourse
Change tracking branch for your Discourse instance


Discourse forum category for hosting (ref) - Topics about hosting Discourse, either on your own servers, in the cloud, or with specific hosting services.

List of managed hosting providers/options
Recommended Hosting Providers for Self Hosters

The recommendation is to keep your host OS updated with the latest security patches. (ref)

Statement: And why we should choose business hosting ? (ref)

Response:
Try setting up self hosting and you will quickly find out :wink:

It’s not too difficult but it will never be “push button and it is done” easy, far from it
 email alone is a giant hairy complex bugbear due to the nature of email, nothing to do with us specifically.

Statement by Stephen/Senior Tester (ref) (03/20/2020)
We (Discourse.com) can’t offer any support or assistance with any third-party ‘one click’ installations. They use unsupported installation methods which have historically had a habit of breaking horribly somewhere down the line. Free community-based support is available for the standard install , which usually takes less than 30 minutes. It may appear pretty daunting, but as long as you step through it carefully and follow the recommendations it’s very straightforward.

Please note that some of the really cheap VPS services don’t offer the correct type of virtualization or dedicated resources, which can cause issues especially when installing docker. Most companies pro-rate their billing though, so you can experiment with several over a period of days or weeks, and still only spend a few dollars for the whole thing.

The cheapest server from DigitalOcean is $5, maintenance for those is pretty minimal. DigitalOcean are recommended due to the ease with which Discourse can be installed into their environment. Other companies such as Amazon (AWS) and Google have more complex network setups, and will require you learn a number of other concepts before you can get up and running.

Most Discourse updates can be done from the browser, with only the occasional need to connect via SSH and update from there.

Server security isn’t that challenging, you can use ufw to secure any non-Discourse/SSH ports and reduce the attach surface of your machine.

Resources to do all of the above exist here on meta. Providing you install in a supported way, and in an environment where Discourse will run we can help you with any basic configuration problems.

How much is Discourse affected by a faster CPU? (03/05/2017 - Before Ruby 3)

Discourse scales more or less linearly with the CPU speed you throw at it . If you want a faster Discourse, have enough memory, sure, but you want the fastest possible single threaded performance .

if you see consistent swap activity, you definitely don’t have enough memory (ref)

How are PostgreSQL upgrades handled in the container? (ref)

Ruby gets updated by providing a new base image for the container.

Postgres upgrades are more complicated, but when it’s needed, the database gets backed up, converted to the new format, and then migrated over. It mostly always works. They typically skip every other Postgres upgrade, so it’ll be a while before it happens again. (If you really care, you can look at the postgres templates in the templates directory of the discourse_docker repo.

Discourse hosting: is there a centralized place (like a status page) I can visit for scheduled maintenance and incidents?

Statement: Sam Saffron sam co-founder

One very important thing to note is that we already monitor your site.

Every 2-5 minutes we will check every site we host from an external location to ensure it is up and running. Our check includes basic stuff (such is, am I getting a 200 response) and advanced stuff (such as, where is the JavaScript payload).

On top of that we use Pingdom to check select sites from multiple geos using ipv4 and ipv6 checks.

Adding to this we have an army of internal alerts that notify us before stuff goes wrong (when initial signs pop up). Machines may be running out of memory, high on CPU, replicas may have issues and so on.

If we notice something is impacting our hosting we will post on twitter. So, https://twitter.com/discourse is your official status page.

As an enterprise customer you have more flexibility, so contact team@discourse.org with your requirements so we can discuss.

Purpose of the Discourse shared volume in a high availability setup - This post has me confused as to what is Redis doing and how it should be configured if we break out Postgres into a separate container. Does Redis get a separate container, what is Redis doing, and how is it connected. TODO

Why did Discourse start running their own Redis instead of using Elasticache?

Read only mode

Discourse can keep a connection open with read only nodes with both Discourse and Redis.

That allows people to keep reading on the site when masters go down.

Statement by Matt Palmer mpalmer team (Dated: 12/17/2017) (ref)
How to downgrade Docker

  1. Stop and delete all running containers . In addition to this bug, Docker also changed some other things in the way that containers are run, and a downgrade while containers are still running will end in tears. If you’re only running Discourse on your server, you can just stop and delete the container with docker rm -f app (your data is safe, and won’t be deleted by this command). If you’re running other containers on the machine as well, you’ll have to figure out what to do.
  2. Downgrade Docker . Via the magic of the package manager, apt-get install docker-ce=17.10.0~ce-0~ubuntu will do the trick. You’ll have to say y to the installation, because it’s a downgrade.
  3. (optional) Make sure Docker doesn’t get automatically upgraded again . That’d really ruin your day, because not only would you have a buggy Docker behind the wheel again, but due to the aforementioned changes in how containers are run, an automated upgrade would likely leave your containers in a kind of limbo state. Not cool.To make sure you stay on a known-good version, create a file /etc/apt/preferences.d/docker.pref with the following contents:
 Package: docker-ce
 Pin: version 17.10*
 Pin-Priority: 9001

Statement - Felix Freiberger fefrei Regular
(ref)
Redis is an in-memory database, used to store state on the server that is more or less volatile. Some examples are scheduled jobs, session data, rate limiting data, 


MessageBus is a system that is used to push messages to the client. For example, if you’re on Discourse while someone replies here, you’ll see a blue number appear an your avatar immediately – that piece of information was sent from the server to your browser through MessageBus.

Statement - Rafael dos Santos Silva Falco team (Dated: 04/16//2016)

The only officially supported installs of Discourse are the Docker based beginner and advanced installs. We regret that we cannot support any other methods of installation.


Discourse up-time (ref)


Beginners Guide to Install Discourse on <OS> for Development
HOWTO Set up a development environment using vagrant (Ubuntu guide)


GitHub Discourse (ref)

Why do you only officially support Docker? (ref)

The only officially supported installs of Discourse are Docker based.

Hosting Rails applications is complicated. Even if you already have Postgres, Redis and Ruby installed on your server, you still need to worry about running and monitoring your Sidekiq and Rails processes, as well as configuring Nginx. With Docker, our fully optimized Discourse configuration is available to you in a simple container, along with a web-based GUI that makes upgrading to new versions of Discourse as easy as clicking a button.

Discourse Hardware Requirements (ref)

  • modern single core CPU, dual core recommended
  • 1 GB RAM minimum (with swap file)
  • 64 bit Linux compatible with Docker
  • 10 GB disk space minimum

2GB swap file recommended (ref a) (ref 2)

Most cloud virtual machine providers do not set up swapfiles as part of their server provisioning.

In particular, upgrading Discourse produces a lot of memory pressure. With a swap file, rather than randomly terminating processes with an out of memory error, things will slow down instead. Having a swap file is a cheap insurance policy that protects you from many other load related failures.

Advanced Docker install guide (ref)

Single Container vs. Multiple Container (ref)

The multiple container configuration setup is far more flexible and robust, however it is also more complicated to set up. A multiple container setup allows you to:

  • Minimize downtime when upgrading to new versions of Discourse. You can bootstrap new web processes while your site is running and only after it is built, switch the new image in.
  • Scale your forum to multiple servers.
  • Add servers for redundancy.
  • Have some required services (e.g. the database) run on beefier hardware.

Two Container Configuration (ref)

The standard cloud install uses a single Docker container. This is the recommended configuration for most users because it is simple and the one that is officially supported at meta.discourse.org. The biggest disadvantage of this configuration is that if a rebuild from the command line is required (typically several times a year when a required component is upgraded) your server will be inaccessible during the rebuild (typically 5-10 minutes).

This two-container configuration using one container for the database and a second for the web server. This makes it possible to rebuild and reconfigure the web server (e.g., to change plugins or do an update) while the old container continues to run. You can then switch to the new server with a down-time of one minute or less. Using this configuration requires that you know when you do need to upgrade the data container (that includes Postgres and Redis) and use a different method to do command-line upgrades.


Docker Documentation (ref)

Docker - Orchestration (ref)

The portability and reproducibility of a containerized process mean we have an opportunity to move and scale our containerized applications across clouds and datacenters.

Tools to manage, scale, and maintain containerized applications are called orchestrators , and the most common examples of these are Kubernetes and Docker Swarm .

Install Docker Engine on Ubuntu (Install Docker Engine on Ubuntu | Docker Docs)

To install Docker Engine, you need the 64-bit version of one of these Ubuntu versions:

  • Ubuntu Eoan 19.10
  • Ubuntu Bionic 18.04 (LTS)
  • Ubuntu Xenial 16.04 (LTS)

Docker Engine is supported on x86_64 (or amd64 ), armhf , arm64 , s390x (IBM Z), and ppc64le (IBM Power) architectures.

Use volumes (ref)

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:

  • Volumes are easier to back up or migrate than bind mounts.
  • You can manage volumes using Docker CLI commands or the Docker API.
  • Volumes work on both Linux and Windows containers.
  • Volumes can be more safely shared among multiple containers.
  • Volume drivers let you store volumes on remote hosts or cloud providers, to encrypt the contents of volumes, or to add other functionality.
  • New volumes can have their content pre-populated by a container.

In addition, volumes are often a better choice than persisting data in a container’s writable layer, because a volume does not increase the size of the containers using it, and the volume’s contents exist outside the lifecycle of a given container.


Docker for Windows (ref)

Switch between Windows and Linux containers (ref)

From the Docker Desktop menu, you can toggle which daemon (Linux or Windows) the Docker CLI talks to. Select Switch to Windows containers to use Windows containers, or select Switch to Linux containers to use Linux containers (the default).


Docker Blog (ref)

Are Containers Replacing Virtual Machines? (ref)


Center for Applied Systems & Software » OSU Open Source Lab

CASS provides clients with services for every stage of a project: designing, developing, testing and hosting. This partnership allows each group to maintain its unique brand while combining their expertise and giving them the ability and resources to take on bigger and better projects.

Potential Hosted Projects (ref)

For development-based projects we also feel that it is important to have an active development community, which is usually characterized by both the number of developers and the frequency of code updates and/or releases. For community-based projects, an active, helpful user community is important.


GitHub OSU Open Source Lab (ref)

osuosl/osl-dockerfiles


Docker Hub (ref)
Discourse at Docker Hub (ref)
Discourse/base page - Basic Discourse container (ref)
OSU Open Source Lab at Docker Hub (ref)


Discourse Self-Hosting FAQ (ref) - A post by Jay Pfaffman/pfaffman A very knowledgeable 3rd-party service provider.

Personal Notes Extended

1 Like

My only concern with self-hosting is the reliability issue; if it goes down at an inopportune time (middle of the night, while someone is on vacation), it would be unpleasant for all. If we can have a few people that are able to jump in when needed though, I would be of course happy to help – I’m just not sure if I can commit to being on-call.

That being said, as @EricGT points out, the paid plans are pretty expensive and we’d have a lot more flexibility, so if it’s fairly stable, it will probably be worth it.

The issues then would be, as I see it:

  1. Hosting - I usually use a VPS provider like Linode; based on the suggest requirements, it would probably be only about $20/month
  2. Backups - Linode can do automatic backups of the VPS (for another 10% of the cost, IIRC), so if it’s one machine with the database & the app server, that might be sufficient; otherwise, we might have to do a more complex setup (e.g. streaming the WAL to AWS Glacier or somesuch).
  3. Deployment itself - as Eric pointed out, the only officially supported method is via Docker, which I am extremely not a fan of, but if nothing breaks (:crossed_fingers:) it should be okay
  4. Email - as the install instructions state, properly-functioning email is critical for a lot of Discourse functions. The Prolog online course is using a mailgun account I’ve set up, which current is costing less than $1/month, but for something like Discourse, I imagine the cost will go up by a non-trivial amount (possibly around the same as the cost of the VPS itself, depending).
1 Like

Agree, but they should be spaced out around the planet, you and I are in Eastern Time Zone and Jan is in Europe which leaves a large gap around the Pacific Ocean time zones.

I was thinking that we should just run a poll and see what the users would expect. I know if I were using SWISH solely for a Prolog class I would appreciate it having more up time, but for this site I think many users would not be bothered if it were down for several hours, I know it would not bother me.

1 Like

Also, I read somewhere (a startup with high volumes that did the research) that this VPS is reliable, and it costs much less: https://www.1984hosting.com/

Worth a try given the pricing.
EDIT: not sure how reliable that report was, but worth a try.

1 Like

I was pretty reluctant towards self hosting. Getting more enthusiastic due to pricing, the consideration that the standard package probably helps for a limited time and the possibility to add our own plugins. Two more data points:

  • I have a proper working mail service for SWI-Prolog on mailgun. That is currently used for a MatterMost platform I use with some people.
  • Does Discourse rely on a single critical node or is it easy to setup with some redundancy? I can easily host a node on the VU research servers, but this isn’t really robust 24x7 service. That is why we have two backends for www.swi-prolog.org.
2 Likes

Good question.

I will search the Discourse forum and possibly post a question there if I don’t feel I have found a solid answer.

EDIT

Does Discourse rely on a single critical node?
Can it have redundancy?

Discourse is deployed in Docker containers and can be run as one or more containers for such needs, see: Single Container vs. Multiple Container (ref)

The multiple container configuration setup is far more flexible and robust, however it is also more complicated to set up. A multiple container setup allows you to:

  • Minimize downtime when upgrading to new versions of Discourse. You can bootstrap new web processes while your site is running and only after it is built, switch the new image in.
  • Scale your forum to multiple servers.
  • Add servers for redundancy.
  • Have some required services (e.g. the database) run on beefier hardware.

Drilling down more into redundancy and based on what I am reading as I have not yet built a working Discourse site.

Discourse is run using Docker. Discourse needs a web server and database server which can run in one Docker container or be in separate containers if needed and the containers can even be on different hardware and different locations, etc.

When thinking about running Discourse with Docker containers one also has to think about the potential need for additional containers, i.e.

  • redundant servers - for high availability
  • upgrading - one container is running while another is upgrading
  • rollback - one container is in production with the latest update and one is on standby with the last stable version ready if a critical error occurs due to the upgrade.
  • testing - testing of integration with other sites such as SWISH, a newly developed plug-in, etc.

Is this easy?

To many variables, e.g. knowledge of installer, how well the instructions match up with the actual environment, is this single container install versus multiple containers, etc. The best way to mitigate it would be to practice a few times and find out.

I hope to do some walkthroughs of the install instructions in the next few days and then will have more hard facts to readdress this with a better answer.

@anniepoo thinks we probably can get a bigger VM or an second VM at the Oregon OSL for free. Can you figure out the specs? The one we now have for us.swi-prolog.org is not much: 2 cores, 2Gb mem and 40Gb disk.

edit I prefer a second.

1 Like

After a few hours of reading topics at Discourse forum related directly to self-hosting Discourse this is the most concise and trustworthy answer I have seen: (ref) (Dated: 02/01/2018)

Provider Price Disk CPU GB RAM Build time Data Centers
Digital Ocean $5 25GB 1 1 10m0.252s US (2), NL, SG, UK, DE, CA, IN
DO Optimized $40 25GB 2 4 5m47.878s US (2), NL, SG, UK, DE, CA, IN
Hetzner CX11 €2.98 20GB 1 2 7m41.816s DE (2)
Lightsail $10 30GB 1 2 8m17.215s US (3), JP, SG, AU, IN
Linode 1024 $5 20GB 1 1 9m46.437s US (3), UK, DE, SG, JP
Upcloud $10 30GB 1 2 7m22.627s DE, FI, NL, JP, UK, US
Vultr $5 24GB 1 1 8m0.930s US (7), NL, FR, DE, UK, JP, SG, AU

Note this is is for a site running based on a standard cloud install (ref) which does not have multiple Docker containers nor any redundancy. But from what I have been reading it seems that custom plug-ins are what cause the most problems when upgrading, and setting up the mail sever is one of the harder problems if you are use to setting up sites in the cloud.

This agrees with Discourse Hardware Requirements (ref)

  • modern single core CPU, dual core recommended
  • 1 GB RAM minimum (with swap file) - 2GB swap file recommended (ref)
  • 64 bit Linux compatible with Docker
  • 10 GB disk space minimum

Our site does not have a high level of demands compared with other sites that host photography, video or have thousands of active users (ref), so to start with for testing purposes I see no reason not to use the minimum and see how things go. I would not jump straight into production with these minimum requirements without testing as the forum does suggest that having a CDN, swap file and mail server that can handle the load contribute to this configuration working.

However we are currently hosted at Discourse which AFAIK does not run sites on Virtual Machines which makes the sites run faster and I have not seen any post that give a relationship between the performance differences.

EDIT

The reason I don’t make lots of noise about redundancy can be summed up in this by Jay Pfaffman 3rd-party service provider. (ref)

I have done installs for several hundred self-hosters and though I do command-line upgrades for some of them, a whole bunch of them just keep going for more than a year before they need my help again.

Many Discourse sites are run by users who don’t know the difference between a # or $ prompt and don’t care. So after an initial install the sites just keep on running for a year or more, even without upgrades.

Ok. If we ask for a second instance and the Oregan OSL with the same specs we have now we should be pretty much ok (2Gb mem, 40Gb disk). If not too hard to setup I’d go for two containers, one running the DB and one the website. I think we do want a quite easy upgrade as I see that Discourse is improving quite fast. Agree?