I am using Webuset.no located in Norway. Best support I have ever had. price roughly $250 a month. running CentOS.
remember, all the solutions mentioned so far are self-managed. So you may find yourself spending a decent amount of time hardening and maintaining the servers regardless of whether you get a dedicated server or cloud VPS.
You may want to consider a managed VPS where the patching and security updates are done for you by people who do this for a living. It depends, I guess, on the nature of the apps you host and how much a data breach would impact you.
I have heard (but not used personally) SquidX is good for managed VPS. I am sure there are others. There is a section on WebHostingTalk on fully managed servers if that is the approach you take.
SquidX does look promising, and well within budget…the main thing I’d like to preserve is at least the potential for node to node communication driven by phoenix channels. But I really just don’t know enough about the whole stack to know what to look for. I also don’t know that I’ll need it, but I’d like to experiment a bit either way.
I have used VPS from a few providers and they all had internal networks that provided machine to machine communication via internal IP addresses (all you need for channels). And the internal traffic doesn’t count towards your monthly bandwidth allotment so it’s perfect for running multi-server apps. Make sure that is on your list of questions for potential hosts.
Hardening servers really isn’t that difficult.
Change default ports, only spin up protocols that you actually use. Make sure iptables is running. Generate keys for ssh. Few other odds and ends. Takes all of 10 minutes once you’ve done it a few times.
Always though keep an eye on the logs daily. Can set up a cron job to email them to you for that.
I realize it isn’t quite the same thing, but to be clear, that doesn’t work on heroku, correct?
Security hardening actually isn’t as big of a concern for me as db backups or various db replication schemes. I suppose its possible that a single cron script can get by until more is actually needed…but I’m not sure I’d even know when its needed.
Glanced back through the thread, and forgot I didn’t even start it; sorry for somewhat hijacking it, and thank you everyone for all the advice!
You can use the Ruby backup gem https://github.com/backup/backup
I use it in addition to my normal backups to back up to AWS.
You could also write your own script but the ruby gem is brilliant.
You’d usually need to backup:
- user uploads
- site files/assets etc
- configurations/emails etc
never said it was hard. my only point is that if someone is running a business and the time they spend admining a server x the amount their time is worth > the cost of a managed vps - self-managed vps then it makes business sense to look at alternatives.
hard, no. good use of time, maybe/maybe not
I don’t see much mention of heroku here.
Heroku appeals to me because many of my side projects are one man shows (ME). So I want a solution that I can at least demo on a free platform. Also, minimal maintenance is pretty important.
If anyone has experience running Phoenix on heroku, I’d be interested to hear it.
@kofno, I deployed a couple variants of our applications to Heroku to great success before we ultimately decided to move them in-house. The decision to move in-house was unrelated to the tech stack, but more related to connecting to other internally-hosted services: LDAP, data warehouse, statsd.
While the prior versions of the applications were hosted in Heroku, we monitored via plug_statsd.
About a year ago, when I was lobbying for Elixir to be used in production, I ran some comparisons between two versions of our application (Ruby/Sinatra and Elixir/Plug) in Heroku, both on Heroku’s free tier and their high performance tier. Ours was a backend api used by another service, so I wanted to test rough real-world usage. Our Heroku dynos were ultimately served out of EC2 US-East, so I spun up an EC2 host to stress test the two implementations on the two performance tiers. Heroku performed quite well and handled our worker tasks within the primary dyno without issue.
Heroku does restart their dynos once a day at a random time. Not usually an issue, but something to be aware of. DNS CNAMEs and SSL termination are both easy to setup and update.
I like being able to pop open :observer and see 4 schedulers on an unshared host for a little over 30 bucks a month.
Thanks for the feedback! Tremendously helpful. I’ve had some good experience with Heroku on other platforms (Rails, Node), but I was curious how Elixir and Phoenix would perform, since that’s how I’m building my current side project.
We’ve been using Heroku to host our Elixir / Phoenix apps here at Carbon Five. Not being able to use observer and such is annoying but otherwise there haven’t been too many issues or gotchas. Overall its been a pretty good experience.
I am using DigitialOcean to host my company projects. It is so far so good.
I think I’d be more inclined to go with DigitalOcean if they had an RDS-ish offering of some sort.
I’m doing a bit of necromancy here raising this thread from the dead but these days I rediscovered dokku. For my personal projects I’m going back to the 20$/month server and dokku instead of the small instance per application. Cheaper and faster. The resources are easily and more optimally distributed between different applications. In the long run I found it cheaper.
- DO: $5 during development, $5+ during prod (you know, depends ). Even cheapest instance is really fast
- Heroku: free plan exists (instance should sleep X hrs/day), good enough for some demos, don’t expect more. Latency quote high, deploy is really really simple (git push)
Related: how do you deploy elixir/phoenix apps? Quote painful point (especially after capistrano experience)
I am using Dokku since I found it is as easy as heroku but with the ability to add background workers in non elixir apps.
Now that I think of it. With a single dyno in heroku you can have background workers in elixir?
Using ExRM releases, I’ve found it’s really not a big deal; deploy a .tar.gz file, stop your app, unpack it, start your app. While I know hot upgrades are possible as well, I haven’t worried about it yet - so far it’s not been worth the effort for my use cases.
A huge advantage is that I don’t need any dependencies installed on the server - everything is in the release package. I have to generate the release on a similar type of machine as the intended server, of course, but that’s no issue as my laptop, desktop and the servers are all running Linux anyway. If it weren’t like that, I’d probably have Jenkins do the release packaging on a build server - probably will do that soon anyway, for convenience.
The guide for using ExRM with Phoenix is pretty nice:
One little nagging detail that can be tricky to get into your workflow w/ releases is Ecto migrations;
mix doesn’t exist in the deployed release. There are good ways to handle that yourself though, by using the exposed functionality within Ecto:
Of course, you can always run the migrations from our dev machine, but that might be trickier to integrate into an automated release flow if you’re trying for that.
i’m running an elixir app on heroku, AMA… (not really, i’m not an elixir expert yet, but I do have it up and running…)