I used it back when they just offered C1 servers (now they offer C2 and C3 too i guess). Though they do offer a one click setup, but there were some restrictions.
Setting up firewalls was not the usual way, i dont remember very clear but there was some complication to it. And if i remember correct, the default install was on Ubuntu 15.10 .
I decided to move my forum from them after some time.
I have now about 3 months of total usage on ScaleWay’s rock bottom VPS. So far my experience has been 100% problem free with no ISP originated downtime. Seems like a good option if you are starting from scratch.
So to summarise, did you need to do anything unorthodox in order to install Discourse on ScaleWay VPS or did you just follow the Cloud Install guide and basically replaced “Digital Ocean” with “ScaleWay”?
ScaleWay and standard Discourse installation process are compatible. They offer standard/typical Ubuntu boxes and virtual servers.
The only unexpected part of the process is that one needs to disable their default SMTP port block and do a hard reboot, in order for the setting change to have effect on the server. And I really mean a hard power on/off reboot, not just issuing a reboot from the terminal. Pulled my hair for some hours until I figured that out.
But that is a one time effort to be done before the actual Discourse installation and from there it is smooth sailing. Bootstrapping and rebuilding times are lengthy thanks to their Atom cores and slow disk i/o.
Hmm, those are both critical for fast, responsive Discourse instances though. 
One does not simply get a Tesla with Ludicrous Mode for 2.99€ month.
OVH’s cheapest offering is a lot faster, but they offer only 10GB storage. This means that you run out of disk space in few months, if you get any action to your Discourse instance. With Digital Ocean you need to triple the budget, and you only get 1GB RAM and also very modest single core performance. Anyway, it’s not too bad actually - see for yourself here.
@erlend_sh Sorry, I was browsing through this whole thread and noticed that yesterday I forgot about another rather unique “feature” of ScaleWay - user needs to choose a Docker specific bootscript, or the installation will fail. IIRC in this case no hard reboot is needed.
ScaleWay continues to run slow but steady. There was one short 15 min network connection break. I tested their support by creating an urgent ticket, and it was responded to rather quickly. There was nothing to resolve at that point though, since the connection came back up, but they explained me that they had a brief network issue. So the uptime is pretty good - 15mins down during the last few months.
Has anyone tried or benchmarked their more powerful plans? While the Atom cores are not ideal, they do come with massive resources. You get 6 cores (non-hyperthreading?), 8GB of RAM and a 200GB disk for just 9.99€/m, as an example.
That would be six really slow cores, though, which might be great if you want to serve a lot of simultaneous page views really slowly, but otherwise is not a great strategy for a web application.
So far, I’m on Scaleway ARM, but I plan to change to x86_64 architecture. What’s your actual plan? This one?
Yes, that’s the one I use for two small or development communities. Been very happy with it so far. Read all the instructions from earlier posts.
Just a quick update that ScaleWay has been consistently stable during my time there. ~100% uptime with no issues what so ever. Still my top choice for small communities or as a development environment.
I set up a small (scout group organization: ~30 users, invite only, low activity) Discourse instance on a VC1S server (the €2,99 plan above) about a week ago. So far it seems to be running smoothly.
I wanted to point out that, instead of changing the kernel as @ljpp described, one can also use the Docker InstantApp which is basically Ubuntu 16.04.1 with docker set up (aufs storage backend by default).
Scaleway users make note of this one:
Hi, I will quickly share my experience with ScaleWay. I used “Starter VC1S” droplet with 2GB RAM, 50GB SSD, 2 x86 cores. Impact on site performance was noticeable, but not unusable. (previously my instance was hosted on Digital Ocean 1GB droplet) Everything was fine for a week or two. Until I started receiving complains from my users about unaccessible page. No error messages were shown, page was just blank. I quickly discovered that this problem can be fixed by clearing browser cache. Blank pages were caused by strange javascript syntax errors and only some users experienced this problem(with nothing similar between them - they had wide variety of devices, browsers and internet connections).
Next I discovered that backups downloaded from this instance were faulty. Site restore on fresh VPS using these backups generated errors and failed.
It seems that that the cause of these problems was bad connection to the server. At least that was the cause for faulty backups. Backups downloaded from web interface were faulty, while the same backups downloaded via sftp were fine. I used FileZilla to download backup files. When download was done I noticed many “connection lost” errors in the FileZilla logs.
After working backup files were retrieved I went strait back to Digital Ocean and haven`t experienced any problems since.
I wonder if ScaleWay has quietly changed something in their infrastructure, or is over selling their capacity. It ran perfectly for months, and now people are running into these issues. My communities did not grow substantially during that time, nor did Discourse change too much since I am on stable branch.
I have since moved my midget sites to Hetzner’s VPS and so far so good.
Are you using https? Those problems sound like they could have been infected by an intermediary.
I was not using https at the time.
(Lest I was unclear. . . ) It’s a good bet that the problems you describe would go away with https.
You were very clear. Thanks for the advice! Https really did not cross my mind at the time.
I’ve seen similar network corruption issues with low-cost VPSes in the past. They all went away when we switched to HTTPS, because corrupted data aborts the connection instead of being saved in the browser cache.
(For certain values of “went away” - it turned a random persistent service problem into a random temporary service problem.)
