secure! at last!
who knew that getting a reasonable letsencrypt wildcard subdomain would be such
a hassle. i ended up migrating off the free heroku service that has kept this
site online for well over half a decade, which has given me some time to think
about how I can keep it online for the next half decade. designing for
sustainable longevity instead of growth.
the site now runs on openbsd on a $3.50/mo lunanode vm. since lunanode runs on
a credit system, I can load funds up-front. $100 gets me over two years of
service at this rate. openbsd felt like a long-term low-churn option. i hope.
cloudflare is back in the mix, but only for a separate domain for the
letencrypt dns01 challenge -- nothing on the main
goes through cloudflare at all. while having a separate domain for this doubles
my domain costs, it feels like the best solution for now.
acme.sh is used for
the actual cert renewal, and it supports cloudflare out of the box.
caddy + easydns. this was my first choice, but after lookign into it, i found
that the easydns api (which is still in beta) is not at a stage i'm
caddy + lunanode dns. i'm optimistic about lunanode, but i've never used
their dns service before. their api seems relatively new, and i would need to
write a custom caddy module to support it.
i took caddy out of the mix once I decided to deploy on openbsd, since relayd
and httpd are really nice.
moving away from heroku also meant losing their managed postgres addon, so the
database is now a lil sqlite3 file. that's what i use when i run it locally,
and i'm not expecting any kind of sqlite-breaking growth.
i put it on a lunanode block volume, thinking that it would be nice for easy
snapshotting backups and reattaching between VMs, but I don't think it was
worth it. The lunanode attach/detach takes a bit of time (and a machine reboot
for openbsd), and just moving the file around is easier and more efficient.
When I get around to taking it off the block storage, I'll set up a cron job
to back up an encrypted copy to tarsnap or something.
the back-end runs gunicorn under a restricted user. deploys are automated
though a git post-recieve hook on the server, and currently get logged with a
timestamped git ref at https://commit--blog.com/static/release.txt . I briefly
considered using github actions for the deploy, but felt that that idea didn't
really fit with my target five-year sustainable project horizon.
i moved all the server customizations and setup scripts into a separate repo.
it's not published yet, but i plan to publish it soon.