The root snapshot and /nix snapshot are registered together in one AMI block device mapping. Runtime deployments should consume the AMI ID directly and should not independently choose a /nix snapshot.

The image is intentionally project-agnostic. It provides NixOS, ZFS, SSM, flakes, and systemd ordering so the Nix daemon waits for /nix.

Publish

The normal flow builds on a temporary EC2 instance, so your local machine does not need to be the same architecture as the target AMI:

cd tofu/ami-builder
./publish-ami.sh --builder-instance-type t4g.large

publish-ami.sh applies this OpenTofu project to create a temporary builder instance and /nix volume. The builder user data installs a ZFS-capable NixOS boot generation, reboots once, seeds the ZFS /nix volume, installs the final boot generation that expects /nix, and powers off.

After the instance is stopped, publish-ami.sh creates the final AMI from the stopped instance, tags the AMI and snapshots, and writes artifact.json.

The OpenTofu state in this directory owns only temporary builder resources. The published AMI and its snapshots are created by the script and are not in OpenTofu state, so tofu destroy here can clean up the builder without deregistering the AMI.

Pass extra OpenTofu variables after --:

./publish-ami.sh --builder-instance-type t4g.large -- \
  -var base_nixos_ami_id=ami-...

Artifact Metadata

The final AMI is tagged with:

Architecture
InputHash
BuilderGitRev
FlakeLockRev
RootSnapshotId
NixSnapshotId
NixosSystemClosure

Do not deregister the AMI or delete either snapshot while runtime deployments use it.