[ehonda]

Host a static website the HN way:

1. Buy the cheapest most unsustainable VPS ipv4 deal out there.

2. Make A record and WWW record and point domain to your new fangled server.

3. Configure server:

apt-get install nginx goaccess

cd website

cp * /var/www/html

Yearly maintenance required: apt-get update, apt-get upgrade

reboot

View traffic stats: goaccess -f /var/log/nginx/access.log

[Tilian]

It's amazing how truly unreliable ultra-cheap VPS providers can be. You're lucky if you even get an upfront notice before they decommission hardware you are relying on, or the entire company just disappears overnight.

Usually you get what you pay for.

[superkuh]

I've used the same openvz instance with my ultra-cheap VPS providerfor as long as google's "Cloud" platform has effectively existed. It's been extremely solid with almost instant support over IRC. I've paid $5/mo for this the last decade.

Sounds like you just made some bad choices. Big companies are only marginally less likely to disapear services than small companies are to disappear.

[cc-d]

Is this company named RN?

You've described my experience exactly.

[nerdkid93]

Google Cloud gives you 1 free f1-micro compute instance. Coupled with a CDN like Cloudflare or Netlify, it should be beefy enough for a static site.

[WJW]

At that point, why even keep the compute instance? You can get them to host your static content entirely.

[jskrablin]

Or setup a Google cloud domain named bucket and put Cloudflare in front.

[s_dev]

Digital Ocean is $5 per month. You could probably run hundreads of static sites off a single instance depending on traffic and these days many websites are just business cards really.

[heavyset_go]

It costs like $2 for the lowest tier VPS through OVH, and they aren't going to disappear overnight.

[z3t4]

Not a problem. VPS's are a commodity, you just switch to another supplier and repeat the steps. If it's too much trouble, make a bash script that runs the setup. If you can spare a few extra dollars per month, sign up to additional providers for redundancy.

[joeyspn]

I used to do this 15 years ago, but it's 2020... rock solid hosting for small projects has been free for a long time and takes 0 maintenance time. Plus making it to the top of HN won't kill your site.

A true hacker way in 2020 would be using IPFS or Dat... =)

[nsporillo]

The last time I tried to maintain a personal VPS I was using it for a Jenkins build server so users could obtain the latest artifacts of some open source programs I work on. That burned me after it got exploited using a Jenkins RCE and a bitcoin miner was installed on the VPS.

Also, the cheapest VPS you can find likely won't ever achieve the level of scale your static website in S3 could achieve. In the rare event you get a lot of web traffic, you're only hosed if AWS is hosed.

[capableweb]

You gotta receive a ton of traffic for Nginx to stop serving static files. I'm pretty sure most of the static websites today could survive on a lite Nginx vps with minimal tuning.

Also, i rather have my server go down than to receive a larger bill from aws, but that all depends on your use case obviously

[nsporillo]

Yeah this is probably true, I've never actually had a nginx instance be overwhelmed myself. I just don't know how much I trust VPS providers that aren't charging a premium $5+/month to deliver quality reliable performance.

The best part of S3 + Route53 is your costs are basically constant. $.50 a month for the hosted zone and then you pay pennies on the dollar for GBs of data transfer. In theory your bill could balloon if you had a hefty static website or some big files left public in your buckets and someone constantly downloaded it.

[eli]

S3 isn’t actually that great at serving a ton of traffic without a CDN in front of it

[nathell]

I've been renting a $3/mo ARM C1 server from Scaleway for 5 years now (a physical microserver) and doing exactly this. It handles being on HN frontpage without a hiccup. I'm very happy.

[iudqnolq]

Serious question: how much more maintenance is required? Could I get away with unattended-upgrades and nginx+wsgi+PostgreSQL?

I ask because actual servers seem like dark magic to me so I want to try to build a product with them, but I can't find anywhere if it's possible to run a reasonably secure server without years of studying.

[geofft]

If you're serving static content, installing Apache, nginx, or any other web server will do just fine. Make sure to set the document root to a directory you're fine being public.

If you're running something dynamic like WordPress, stay extremely on top of patches, unfortunately, and be super cautious about what plugins you use. (This is one of the better reasons to use a static website.)

If you want to run a Postgres for your dynamic website, configure it to listen only to localhost or only via UNIX sockets.

Make sure you keep your software up-to-date. unattended-upgrades is a great idea for OS-provided software.

Be careful about where you get software from. More than just "get it from somewhere trustworthy," the big concern here is to get it from someone who is applying software updates. For most OS-ish things, you want to get them from your distro; try to avoid downloading e.g. PHP from some random website, because you won't get automatic updates. For a few things - especially things like WordPress - I wouldn't trust the distro to keep up, largely because the common practice is to release security fixes by releasing new versions, and distros are going to want to backport the fixes, which is slower and not always guaranteed to work.

As another commenter mentioned, turn off remote password logins and set up SSH keys. (Most VPS providers will have some form of console / emergency access if you lose access to your SSH keys.)

[cmroanirgo]

I run my sites, all static on a VPS, but I do the authoring in a single multi-site wordpress install and use 'Simply Static' plugin to publish the result. The benefits are pretty awesome:

heaps of templates (because I'm often lazy), 1 stop shop for patches, locked down plugins (child sites can't install plugins, only enable/disable), and only one place to look for problems (& you can lock the wordpress site to a single IP if you always want to use it from a single place).

FWIW, I never groked AWS & it's ping times in my country are about 1/2 as good as local providers. (15-30ms for local, vs 50-100ms for AWS local). Speed matters.

Also, my use case is to 'fall over' (meaning: fail/stop working/be unresponsive) wrt DDOS, whereas I know many here are 'must not fail' (with varying levels of acceptability). So, I write concise, low bandwith consuming websites that appear instantly (to my local market users).

[iudqnolq]

Thank you for the advice. I've tried out passwordless login and found it more convenient, so that's not a problem. I'd want to be deploying a Python app I wrote myself, and some static files.

[mr_toad]

It’s not that bad. A day or two initially, then an hour or two every six months, depending how much work you put into automating it. It’s definitely a good way to learn.

Write everything down! Every command you type. You don’t want to come back in sixth months time and have to relearn what you did the first time.

If you’re feeling ambitious you can script almost the entire deployment from provisioning a machine through to rsyncing the content. It’s pretty fun to run a bash script or two and see an entire server pop up.

[indemnity]

As a former sysadmin, this is still a lot of pain in the ass. One Terraform file that keeps my S3 + CloudFront sites configured, run once a month to ensure LetsEncrypt certs are rolled, and done.

Have maintained enough servers for a lifetime, I’d rather be coding!

[iudqnolq]

Thanks for the advice! I was stuck thinking I'd have to learn something like Ansible to automate deployments, bash scripts is a greatidea.I

I have Linux on my laptop and I've been trying to document what I configure with heavily commented bash code, but I've run into issues with editing config files. I frequently want to say something like "edit this variable to this value" but sed feels too fragile and easy to mess up silently, relacing the entire file is silently badly future incompatible if other entries in the config get changed in an update, and appending to the file so the last item overrides feels hacky and doesn't always work.

How does everyone else do that?

[zelly]

Managed cloud products seem like dark magic to me. A VPS or EC2 VM is just like the computer I'm using right now. There's no magic. If something goes wrong, I can fix it as if it were on my local machine since it's often literally the same kernel version, same architecture, same shared libraries, same software from the same package manager. Performance tests on the local machine very closely predicts that on the server. On a serverless cloud product, to fix something deep, the tools at my disposal are a maze of buttons on a web GUI or CLI that sends the same opaque API calls the web console does.

[root_axis]

Do not fear running your own server. There is no such thing as perfect security and neither is the cloud inherently secure. Many of the infamous data leaks you've heard about in recent years occurred on cloud-hosted systems. Ultimately, if security is a concern, you need someone that understands security, regardless of where its hosted.

[jjoonathan]

Yes, you can absolutely do that, but shouting that message from the hilltops isn't a good business model in an industry with ADHD.

[iudqnolq]

What do you mean? I asked because I constantly hear that running my own server is better and cheaper on HN, and also that running a server is really hard if you didn't grow up memorizing binders of man pages.

[jjice]

I felt the same was last year before I had ever deployed a server publicly. It's really not that bad for small things. I run Nginx and some docker containers and proxy to those docker containers for certain subdomains. Now that I know how to do it, I moved from AWS to DO and the new setup was probably 20-30min to get everything set up, including Let's Encrypt.

[ehonda]

you can change the ssh port and use a ssh key instead of a password. Don't worry about a firewall or fail2ban. That's about all. Also run everything from root.

Repeat above steps once vps provider goes out of business (as someone else also pointed out)

[e12e]

> you can change the ssh port and use a ssh key instead of a password.

I'd advice against changing the ssh port - I don't think the (small) inconvenience is worth the (tiny) benefit to obscurity.

I would always recommend turning off password authentication for ssh, though.

(along with disabling direct root login via ssh, but root-with-key-only is now the default - and if you already enforce key based login, it's a bit hard to come up with a real-world scenario where requiring su/sudo is much help for such a simple setup).

I would probably amend your list to include unattended-upgrades (regular, automated security-related updates - but I guess that's starting to be standard, now?).

You will probably need an ssl cert, possibly from let's-encrypt.

At that point, with only sshd and nginx listening to the network - avenues of compromise would be kernel exploit (rare), sshd exploit (rare) or ngnix exploit (rare) - compromise via apt or let's-encrypt (should also be unlikely).

Now, if the site is dynamic, there's likely to be a few bugs in the application, and some kind of compromise seems more likely.

[iokanuon]

Anecdotally, changing the ssh port on a very low-budget VPS is worth the effort because the CPU time eaten by responding to the ssh bots can be noticable.

[allenskd]

This has been my experience as well. I remember having a VPS with digital ocean a long time ago and it was getting hammered badly with bots. Changed the ports, made pubkey authentication only and installed fail2ban for future pesky bots did the trick for me.

To be honest I don't think the people controlling those bots want to deal with us that makes it harder for them to gain access. Instead why not happily hammer away everyone's else port 22 with the bare minimum configuration? Those who enhance the security were never the targeted audience to begin with.

[pm90]

> Those who enhance the security were never the targeted audience to begin with.

This is pretty insightful. Statistically, attackers are probably mostly looking for badly configured machines which are easy to exploit rather than hardened systems that take a long time to penetrate.

State actors and obsessed attackers are different, of course. But statistically even taking care of using the simplest precautions keeps one out of the reach of the broad majority of such attacks.

[banana_giraffe]

I'm more familiar with AWS. There I just firewall SSH to just my IP (with a script to change it for the laptop case, or use mosh), and thus spend no CPU time responding to ssh bots.

Do VPS providers offer some sort of similar firewall service outside your instance?

[e12e]

I don't think low budget vps providers typically allow this. That said, fail2ban works OK, as does manual iptables (now nftables) - unfortunately /etc/hosts_allow is deprecated[1].

If you don't know that you'll be able to arrive from an IP or subnet - another option would be port knocking. (eg: knockd). Although, I'd try to avoid adding more code and logic to the mix - that goes for both fail2ban and knockd.

[1] ed: Note, the rationale for this is sound: the firewall (pf or nftables) is very good at filtering on IP - so better avoid introducing another layer of software that does the same thing.

[CameronNemo]

You still get hit by bots, AT least some of them. If you are really concerned you want to use port knocking.

[e12e]

That's not something I had considered - I suppose the handshake does take up some cpu.

[iudqnolq]

I'm inexperienced, but relatively confident if I use an off the shelf login module to protect everything but the login page, the handful (literally) of users with creditials are internal to the organization and trusted with underlying the data anyway, and the data itself is essentially worthless to outsiders, I'm pretty safe.

My thinking is that even if I for example fail to sanitize inputs to a database or displayed to other users that won't lead to an exploit absent a bug in the off the shelf login module or someone attacking their colleagues (in which case there are other weaker links).

The organization I'm building this for has other moderately sensitive systems on an internal network, but the server I'll be managing will on the public internet. The site I'm building will export CSV files to be opened with Excel, so I suppose if the site I build was compromised it could be used to get an exploit onto a computer in the network. Still I presume if they're facing that kind of attack they'll have plenty of other weak links like documents spearphished to people and I'm pretty sure the sensitive systems are on a separate internal network.

Is my confidence crazy?

[e12e]

I don't think you're crazy.

But I also think that I would trust eg apache/nginx basic auth, more than login/session handling at the application level (php/ruby/... with users in a db).

Assume at least one user has a dictionary password, and suddenly you'll want to enforce 2fa via otp or similar - for peace of mind.

As a general rule, I tend to assume a targeted attack will succeed (no reason to make that too easy, though) - what I aim to avoid are the bots.

They'll likely be brute forcing passwords, blindly trying sql injection - along with a few off the shelf exploits for various popular applications (eg: php forum software).

[fragmede]

> I'd advice against changing the ssh port

Hard disagree, even if for as simple a reason as port 22 gets inundated by drive by hacking attempts, making the log files virtually useless.

Running telnet with no password on any port would be, but having ssh on a non-default port isn't trying to achieve security through obscurity.

[zelly]

Ideally you should block all SSH traffic except from a VPN (not a public one obviously). In that case it wouldn't matter whether you changed the port.

[joking]

there are literal dozens of sites who offer free static site hosting, from github pages to firebase hosting, why advantage you get using a VM?

[tastroder]

A machine I can actually use, portability. I have enough servers, adding nginx and certbot to one isn't hard. Adding instances and load balancing isn't either should it be warranted. The "serverless" approach is the new one and thus the one that should seek justification.

[pm90]

> I have enough servers, adding nginx and certbot to one isn't hard.

I think this is key. If you have resources that are already serving things, the marginal cost of serving something else is low.

For a typical person not running servers for personal services, the upfront cost does not seem justified, when its so easy (and cheap) to setup and use the alternatives.

[scarface74]

If you’re hosting static content, are you really worried about the “lock in” boogeyman?

[amerkhalid]

Server side stats instead of Google Analytics is big one, imo.

[manigandham]

You can also just get a micro instance from the major cloud providers. Just as cheap, and more reliable and usable with all the cloud tooling.

[scarface74]

But then you have to manage the instance. Once you set everything up with S3, your deployment is literally.

   aws S3 cp $your-local-directory S3://your-bucket

[manigandham]

That's out of context. I was responding to OP getting a cheap VPS provider. If you want a cheap server then it's better to just get a tiny instance from a major cloud instead. Most also have free tiers.

[scarface74]

The top of his post was

“Host a static website the HN way”

It would be overkill for a static website.

[manigandham]

Then reply to their post instead?

[dragonwriter]

> Buy the cheapest most unsustainable VPS ipv4 deal out there.

[...]

> Yearly maintenance required:

Well, presumably, find the new cheapest, most unsustainable VPS ipv4 deal, the previous one not having been sustained.

[veeti]

Replace nginx with Caddy for zero config HTTPS.

[htfy96]

I would wait for Caddy 2 at this point, for I found 1.0 doesn't work very well when your site gets complicated - many directives conflict with each other. Fortunately it seems that most of these are solved in 2.0.

[mholt]

Don't wait, start using it now while we're in beta so we can fix problems before they affect everyone!

[mholt]

And even bring your config with you: https://github.com/caddyserver/nginx-adapter

[mr_toad]

For extra work add a let’s encrypt client, configure Nginx to do ssl, and set up automatic renewal.

[ummonk]

And watch it go down from the load when it gets linked to on HN.

[9HZZRfNlpR]

Static site? You can serve insane amount if static content with cheap vps box. Are people now only using so called serverless tech and forgotten how it works underneath all the buzz words? 5 dollar digitalocean box can serve double the HN traffic and more.

[cowsandmilk]

The described cloud front configuration would be less than $5/month. How? As you point out, the cheap VPS box can serve insane amounts of traffic, so AWS doesn’t even need hardware equating to that box to host your content.

[thinkxl]

> Host a static website the HN way

Gatekeeping alert!

Fortunately, there is more than one way to do things. I've been in HN for a while now and I don't do any of this. I was doing it when I wanted to learn, but now I need to get a project launched without any burden so I deploy it to ZEIT Now which is not the same as OP, but you get the idea.

[scarface74]

You realize he was being sarcastic right?

[thinkxl]

Nope. It's really hard to distinguish these days!

[tastroder]

How is that "without any burden"? That's paying somebody else to take that burden for you, buying into their non-standard tooling, and hoping that they outlast whatever project you are hosting.

[thinkxl]

You pay for convenience. Someone else takes care of the server. I pay them $5 per month for the site/app I pay $15 for the database in other place and I charge +$150/hour while I work in something else instead of dealing with the server. That's without any burden.