Hacker News new | ask | show | jobs
by cookerware 4402 days ago
my current setup on DO, I would like some inputs.

website hosted on 1 droplet. additional 1 droplet per every customer is deployed through Stripe and DO api.

DO let's you save a snapshot and load it to the droplet. I have a snapshot that is basically a copy of my 'software'. It's a LAMP stack with init script to load the webapp from git repo.

Customer logs in at username.mywebapp.com

The beauty of this is that I never have to worry about things breaking or becoming a bottle neck. if one customer outgrows themselves, they won't affect other resources. It has linear scalability, new customers, add a new droplet. I don't need to worry about writing crazy deployment scripts although I use paramiko to ssh in to each server when I need to get dirty.

The main website is mostly static content. I could host it even on Amazon S3 but currently using cloudflare.

Updating the product code requires me to restart the droplet instance. However, I test things out on another staging droplet. Once things work on there, I use the DO api to iterate through all the customer droplets and do a restart.

1 comments

The obvious remark is why do a new webapp deployment per customer instead of a multi-tenant app ? Multi-tenancy requires more code in the web-app to isolate accounts, but it will mutualize and consolidate web servers.
I did it because a new webapp deployment costs nothing, no extra work involved at all with DO, just add a snapshot and ssh key to a new droplet. If something needs to be consolidated, I just use DO api and paramiko to ssh into each droplet and run new commands. If it's updating the webapp across all customers, it's a matter of issuing restart command to all the droplets via API.
Aren't you paying for hosting on each droplet though? Consolidating would save you that money, but I guess this wouldn't have a huge impact if the income per customer is a lot larger than the cost of an additional droplet.