Hosting options (Discourse hosting vs. 3rd party hosting)

Installation Hosting
1

Hi guys,
Could anyone please clarify to me what are the benefits of using the hosting options featured here
vs. hosting with https://www.communiteq.com/ ?

Thanks <3

6 Likes
2

(full disclosure: I’m a co-founder of Discourse)

Hosting is our core business at Discourse. The software is available for free, but its current pace is sustained by our hosting plans. By going with us you are directly helping us fund development and making it better for everyone else who uses it!

Technically speaking, we host all our customers on dedicated bare metal servers for performance. Our response times are considerably higher than cloud environments due to lack of virtualization which has a particularly bad penalty on Ruby applications.

We have built in quite a lot of redundancy to this set up. No customer runs on a single server regardless of plan. Everything is spread out to avoid hardware failures and for extra speed.

12 Likes
3

(full disclosure: I’m a co-founder of Communiteq (formerly DiscourseHosting) :sunglasses:)

The most important differences (if you ask me):

  • We offer a number of preinstalled plugins on our plans, and we make sure we’ve tested everything thoroughly.

  • We’re (a lot) less expensive, (but with Discourse.org you’ll fund the development of Discourse).

  • We offer pretty decent performance for a pretty decent price.

  • There are no limits on the amount of staff users on every plan if you host with us.

  • We can host your forum outside of the USA on request, for instance in Europe or in South-East Asia.

  • We offer a SLA with 99.9% uptime guarantee. If we don’t make that, you get your money back. We do a lot better than that, by the way.

  • We make daily off-site backups for disaster recovery.

  • Provisioning your forum takes less than 5 minutes.

10 Likes
4

Discourse.org hosting is indeed a lot more expensive, especially for folks that can spend the 30 minutes installing on digitalocean. If I had the money however, I would consider it to fund discourse development, as you said. The free customer support here has been worth its weight in gold.

I think another good comparison would be Communiteq (formerly DiscourseHosting) versus digitalocean - are you offering better performance for the same price?

1 Like
5

We aim for people and businesses that don’t want to deal with the hassle of setting anything up at all.

But even for people who don’t mind spending time on technical details: our price/performance ratio compares to DO very well, and with us you get some extra benefits:

With us, you get an autoprovisioned, automatically updated forum. We offer pre-installed and tested plugins, off-site backups and an uptime guarantee: If you’re on DigitalOcean and you mess up, you’re on your own. We don’t mess up at all :smile:

BTW we have free customer support as well.

4 Likes
6

Agreed, once we’re in a position to we’ll be moving across to discourse.org. I’m much more interested in supporting the project and ensuring it sticks around than I am in paying a third party.

Unless Communiteq (formerly DiscourseHosting) makes some kind of contribution to discourse.org, does it @michaeld ?

7

It sounds like you might be a good fit for people with limited or no technical expertise, that have existing traffic. I recall that you handle migrations of large forums, which would’ve clinched it for me (since we had to spend a month dealing with all the migration bugs from a ruby on rails forum)

I have to be upfront that when I reached out to you guys about migrating, you kept saying you’d get back to me but never gave me a solid yes/ no on whether you’d be able to handle it. I would suggest that you guys don’t overpromise, and give a clear no when you’re overloaded.

Compare that to discourse which is constantly dealing with new feature requests, but when they can’t accommodate something, they’ve always just straight up told me no. Managing customer expectations is a really good thing, whether it’s a huge task such as a migration or a small tweak.

2 Likes
8

I have just looked in our support system and yes: we could indeed have done better in your case. My sincere apologies and thank you for the feedback!

2 Likes
9

It’s true we tend to push our customers towards the latest release, but we have many containers running different versions. The only servers that absolutely run on tests-passed are try and meta.

We usually have a good idea when we are introducing a commit that is risky (for example, a big feature like translation overrides) and we delay deploying all the sites before introducing the risky stuff so that we can run them for a few days on meta/try before possibly breaking for our customers.

Our enterprise customers can run whatever branch they want and even choose when to deploy their own sites via a control panel if they like. They can also provision a staging instance to test their code against.

We prefer to manage it and keep them closer to a stable release branch (with the exception of security fixes.)

Other stuff I probably should have mentioned in my original post:

  • All customers get a CDN for added front end performance

  • We do migrations for customers if they commit to a contract

  • We also do frequent backups and keep them off site

The chances are, if there is something I didn’t outline that we provide it! Just ask us :slight_smile: This was just an off the cuff response and not a detailed grid of our differences.

9 Likes
10

Thanks for clarifying. I’ve edited my post and removed the bit about the branch differences.

5 Likes
11

They contribute here and they contribute in general by promoting the growth of Discourse!

It is absolutely not our goal to be the only host of Discourse, we are an open source solution. What you give away for the greater good will come back to you tenfold.

24 Likes
12

Thanks guys, very helpful!

13

Very well stated Jeff.

I love what you guys have done and wish you and you team continued success!

2 Likes
14

Hi Robin,

This makes me a bit nervous. In the old old days we did rigorous test cycles maybe pulled in a few hand selected customers for a Beta cycle, then shipped something stable. I know that whole philosophy has long since been abandon (no more Mythical Man Month approaches) and end users pay to suffer through releases that are really just Alpha, and may get an update to a Beta 1.x or two, while another Alpha is being coded and handed out in a 2.0

So now I’m worried about handing over alot of money per month to have everyone in my forum (which then reflects on me) be Alpha and/or Beta testers because that’s the “way things are” now.

So … tell me about your amazing QA staff!

And tell me you have some hands on testing - that it’s not just 100% automated testing. Human eyes and hands have a role in the QA process.

And tell me I won’t be suffering though continuous Alpha/Beta nonsense.
Tell me you’re going to make me look good when I put my name next to yours.

thank you!

  • Michelle

p.s. yes of course all software has bugs! and certainly “stuff happens”
just looking for “stuff not happening all the time”
ya know?

15

It is up to you, if you want to be hosted by us and have better control of cadence of deploys, we have enterprise plans that can cater for you.

Our standard plans do not offer you this level of control, instead you can rest easy that as issues arise we will correct them promptly and you will not need to wait 6 months for the next release train like you do on many other platforms.

4 Likes
16

Better question, you’re fearful of alpha/beta by what you acknowledge to be experience from the ‘old old days’ - knowing what you do now from the above, and looking at existing hosted customers, could you see anything which suggested the sites weren’t running release-quality code?

You’re right that external impressions matter, what was yours when you looked here at meta and the other customer sites the team hosts?

1 Like
17

Just wondering wich CDN are available for your standard hosting @codinghorror

1 Like
18

We use KeyCDN for all our hosting tiers.

2 Likes