I'm surprised how many people here are snow-flaking their own web application servers instead of just using Heroku. Heroku is $25/dyno/month. At $100/hr for a dev a Heroku dyno costs 15minutes of dev time per month. If you spend just a day tinkering with your application server VMs or updating docker images running your Rails app every month — you could have bought 32 Heroku dynos instead.
Ask HN: Where do you deploy to in 2018 and how?
51–60 of 85 posts
Re: Ask HN: Where do you deploy to in 2018 and how?
#52I just listened to the web platform podcast [0] episode about WeDeploy [1]. Haven't tried it yet, but it sounds really nice.
Re: Ask HN: Where do you deploy to in 2018 and how?
#53Take a look at https://nanobox.io/, I'm using it for side projects and it's great and cheap (I'm not related to them)
Re: Ask HN: Where do you deploy to in 2018 and how?
#54Take a look at https://nanobox.io/ , I'm using it for side projects and it's great and cheap (I'm not related to them)
Also the dev experience that it give is awesome
Re: Ask HN: Where do you deploy to in 2018 and how?
#55I know this post is young but surprised not to see Linode on here yet. We are deploying to Linode and have recently switched from Puppet to Saltstack to manage our servers. There's a bit of Fabric and Capistrano to glue it all together.
How does Linode compares to DigitalOcean? I see that at least price wise DigitalOcean looks cheaper.
Re: Ask HN: Where do you deploy to in 2018 and how?
#56Most of my projects are Rails-based, and I tend to use DO [0], and have just discovered Hatchbox [1] to deploy. Super easy for side-projects to get started and deployed. Taken deploying side projects from days to minutes. [0] https://www.digitalocean.com/ [1] https://www.hatchbox.io/
https://www.nanobox.io is also a great option for Rails... or many other languages & frameworks.
Contained developer environments, simple command line deploys to VPS, and a free tier that can handle most hobbyist application needs.
I deploy Rails & Elixir / Phoenix apps with Nanobox
Re: Ask HN: Where do you deploy to in 2018 and how?
#57I do things in an old-school way. 2 Bare metal servers at different data centers with totaluptime.com acting as a load balancer with auto-failover.
Deployment is done via SFTP by pressing the publish button in Visual Studio. This will deploy to the inactive server. I then manually trigger tests on GhostInspector (this could be automated via API) to make sure I didn't break anything. Then I run a custom script to make the load balancer redirect traffic to the upgraded server.
Solo founder, small bootstrapped business generating 50k/month with 1000 paying customers. Hosting costs are under $500. I could double the number of clients without needing to upgrade the hardware. I looked into moving to AWS or Azure, but can't justify paying 4x more for the same performance.
Re: Ask HN: Where do you deploy to in 2018 and how?
#58I know it's not useful for you, but: In our own datacenters, using Kubernetes on baremetal.
I'm looking into this. How and how difficult is it to get K8 onto baremetal? Could you point me towards tooling and best practices for running K8 on baremetal?
The short answer is: It's pretty ugly. I don't know the details, but we PXE-boot and install CoreOS, then run kubelet using rkt (using a systemd service). The other k8s components (etcd, apiserver, controller manager etc.) are managed by the kubelet using static manifests. Persistent volumes are backed by a separate storage appliance via NFS.
Our team built this entire process ~2 years ago, when we started using k8s. We would probably use some off-the-shelf parts today, but practically nothing existed back then.
Re: Ask HN: Where do you deploy to in 2018 and how?
#59Flynn [1] is worth a look (having come from dokku). Heroku-like and runs as a cluster. [1]: https://flynn.io
Are they still knocking about? They used to do a weekly blog post but nothing since March 2017
Re: Ask HN: Where do you deploy to in 2018 and how?
#60Mesos running on AWS, almost entirely with EC2 spot instances.
We were big Heroku users as well, so carried over a number of Heroku patterns. For example, configuring everything with ENV vars, lightweight load balancing, grouping apps into several deployable targets, etc.
It’s certainly not better than Heroku in most ways, though there was no plausible way for us to continue running our workload on Heroku.
(Edited: typo)