AWS on East of the Sun, West of the Moon

Mastodon server

Wed, 31 Dec 2025 00:00:00 +0000

Status

Active since December 2022.

Moved from AWS to Hetzner in November 2025.

What

My personal Mastodon server. The accounts on there are all me, at this time.

Where

https://strangeweb.page/

I wanted to keep this relatively separate from other projects, so I registered a .page domain.

How

When I migrated to Hetzner, I simplified the setup a bit:

A single VM

More than enough CPU, RAM, storage, and of course an IPv4 and an IPv6 address.

Access via ssh locked down

Only my home IP address can get in. Easily updated when that changes (which is rare).

The other ports available

Port 80 (http, in practice really only for LetsEncrypt, but also the classic http to https redirect), and of course 443 (https) for the main attraction.

Still using the S3 bucket

I plan to migrate that to different object storage in the near future.

Terraform code

It creates the VM, updates the DNS (A and AAAA records which now live at deSEC.io), as well as reverse DNS managed by Hetzner, then throws cloud-init at it.

The cloud-init setup

This takes care of basic conveniences (things like emacs, jq, rsync, and others) but also installs dependencies for Mastodon and prepare it most of the way (skipping the interactive configuration of Mastodon itself).

Code and related things

Mastodon instructions for setting up your own server

The Infrastructure as Code at https://codeberg.org/.

Previously

The setup in AWS (from 2022-2025) was as follows:

Basic Virtual Private Cloud (VPC)

Pretty standard setup. A subnet for public facing things (which is the only things in here right now), and one for resources that don't connect out to the internet. Right now there aren't any of the latter, but it is good to be prepared

A bastion server

A locked down instance that is intended to be the only way to get into the VPC with ssh, with an IP address that is separate from the actual service.

The actual Mastodon server

An S3 bucket

This is where Mastodon stores media associated with posts (in the timeline of my accounts, or my own), with a CloudFront shield in front of it

Terraform code

This managed all of the above.

For Mastodon upgrades

I created a script to temporarily bump up the instance size, because it was unhappy for some of those steps but perfectly content running in a smaller instance during normal operations.

WARN Act Bot

Sun, 13 Jul 2025 00:00:00 +0000

Status

Active since around April 2023.

What

As I understand it, there are WARN Acts in most states (maybe all) that require employers of companies over a certain size to give a heads-up to the state when they plan to let go for one reason or another. This could be for permanent closure of a place of business, redundancies for whatever reason, and some other reasons I can't think of right now. Many states make the notices available in some form on the web. Sadly they don't seem to have considered standardizing that, so automation based on the content found online is a challenge.

In my case, I decided to automate checking the notices for the California EDD, and post the incremental changes (summarized where possible) on the Fediverse.

Where

https://sfba.social/@warn_act_ca (originally at https://botsin.space/@warn_act_ca, but that server shut down at the end of 2024).

How

The setup (in AWS) is as follows:

An S3 bucket to maintain state from one run to another
A few Systems Manager Parameter Store entries for the knowledge of where the bot is and the token to post to its timeline
A Lambda that is triggered from EventBridge on a regular basis that checks the California website
An SQS queue through which to manage the posts to the bot account, with a Lambda consumer that does that work
Terraform code to create these resources and some tangentially related ones

Cost

$0.00!

Actually, the dedicated AWS account in which this runs had a bill for (literally) a few pennies one time, apparently related to AWS Cost Explorer of all things, but otherwise the monthly bills have been $0.00 since I started.

The reason is that all of the service usage (S3, Lambda, SNS, SQS, CloudWatch, and data transfer) are all flying well under the limits of the permanent AWS free tiers. The biggest risk is probably S3 where the it's running up a bill of about $0.005 per month, so each month that is rounded down to $0.00 but when you request an annual total it lists that as ~$0.05. 😁

Code

https://codeberg.org/jochie/WARN

Website

Mon, 13 Nov 2023 00:00:00 +0000

Status

Active in its current form since November 2023 and its current location since March 2025.

What

My personal website.

Where

Right here.

Content

Everything on here has been generated once by a so-called SSG and then dropped in place.

The content is generated with Hugo. I picked the Ananke theme, and made some minor modifications:

Modified the default Hugo RSS template (layouts/_default/rss.xml):
- Change the feed to include full posts instead of just the summary
- Add <category> tag(s)
Copied and modified the default single (post/project) page (layouts/_default/single.html):
- Include an optional "Updated …" bit after the original post date
- Move the context menu (with the table of contents and related posts) before the content, which places it to the left of the text, or at the top of page instead of at the bottom in a small screen situation
Copied and adapted the main page (layouts/index.html) just to make the text there not be centered.
Copied and adapted the footer (layouts/partials/site-footer.html) just so I could make the copyright years be a range instead of just the current year. I tried to put the beginning of the range in the copyright configuration setting but then that ended up looking funny in the RSS source

Beyond that, I've left the theme as-is and I'm taking advantage of its (and Hugo's) features.

Hosting

Until March 2025 the static site was hosted in an AWS S3 bucket, made available through a Cloudfront distribution to make it available via https.

At that point, I moved it to statichost.eu, which specializes in hosting SSGs, directly from Git repositories, and hosting it with http and https.

Keeping up with the Joneses?

As so often happens, I looked away for one minute (alright, closer to 4-5 months) and the version of Hugo that I get when I do a fresh install (from Brew) is a bit different than what I started with, and that is going to break some things.

To give myself a stable work environment and breathing space I decided to run the hugo command inside a quick'n'dirty container:

The Dockerfile

  FROM cibuilds/hugo:0.119.0

  EXPOSE 1313

A super simple Makefile

  hugo-docker:
          docker build --tag myhugo .

  server-beta:
          docker-helper server --bind 0.0.0.0 --environment beta

  server-live:
          ./docker-helper server --bind 0.0.0.0 --environment live

  deploy-beta:
          ./docker-helper --environment beta && ./docker-helper deploy --environment beta

  deploy-live:
          ./docker-helper --environment live && ./docker-helper deploy --environment live

And a shell script to glue it all together:
```
  #!/bin/sh

  if [ $# -eq 0 ]; then
      echo "Usage: $0 <hugo-arguments>" 1>&2
      exit 1
  fi

  DIR=$(git rev-parse --show-toplevel)
  docker run -v $HOME/.aws:/home/circleci/.aws -v $DIR:$DIR -p 1313:1313 -w $(pwd) -it myhugo hugo $*
```
That script fires up the container with only the current Git repo exposed within the container, and starting off at the current working directory as well, then running the hugo version that I grabbed. It also shares ~/.aws for the deployment steps.

Now I can run a command like this and I can sanity check that the site is going to look ok with that particular version, and then later figure out what needs to be fixed as I nudge the version along at my own pace:

make server-beta

And then deploy when I'm happy:

make deploy-live

Noting that now that I've moved to statichost.eu the deploy-* targets are obsolete, but it's still useful to test locally with server-*.