diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 27d933cdc7..b3af981630 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -1,42 +1,30 @@
+# This workflow builds every branch of the repository daily at 20:22 UTC, one hour after ublue-os/nvidia builds.
+# The images are also built after pushuing changes or pull requests.
+# The builds can also be triggered manually in the Actions tab thanks to workflow dispatch.
+# Only the branch called `live` is published.
+
+
 name: build-ublue
-on:
-  # Build *every* branch at 10:20pm UTC every day (1 hr delay after "nvidia" builds),
-  # regardless of the branch names. (Not just "live, template and main" branches.)
-  # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
+on: # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
   schedule:
     - cron: "20 22 * * *"
-  # Build automatically after pushing commits or tags to the "live", "template"
-  # or "main" branches, except when the commit only affects "documentation" text files.
-  # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#push
   push:
     branches:
       - live
       - template
       - main
-    paths-ignore:
+    paths-ignore: # don't rebuild if only documentation has changed
       - "**.md"
-      - "**.txt"
-  # Build pull requests whenever they are opened or updated, to make sure they
-  # work. The build won't be deployed, since we filter out PRs in the deployment
-  # stage. Note that submitted PRs run the workflow of the *fork's* own primary
-  # branch, using the fork's own secrets/environment. Please be sure to sync
-  # your primary branch with upstream's latest workflow before submitting PRs!
-  # For pull requests, we build *any* branch regardless of name, to allow "build
-  # checks" to succeed for typical PR branch names such as "fix-something".
-  # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request
   pull_request:
-  # Build when manually triggering this workflow for a branch. This allows you
-  # to build any branch, even if it's not listed in the automated triggers above.
-  # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
   workflow_dispatch:
 
 env:
   IMAGE_REGISTRY: ghcr.io/${{ github.repository_owner }}
 
+# Only deploys the branch named "live". Ignores all other branches, to allow
+# having "development" branches without interfering with GHCR image uploads.
 jobs:
   push-ghcr:
-    # Only deploys the branch named "live". Ignores all other branches, to allow
-    # having "development" branches without interfering with GHCR image uploads.
     name: Build and push image
     runs-on: ubuntu-22.04
     permissions:
@@ -45,29 +33,34 @@ jobs:
       id-token: write
     strategy:
       fail-fast: false
+
       matrix:
+# !!!
+        # Add recipes for all the images you want to build here.
+        # Don't add module configuration files, you will get errors.
         recipe:
           - recipe.yml
+# !!!
 
     steps:
       # Checkout push-to-registry action GitHub repository
       - name: Checkout Push to Registry action
         uses: actions/checkout@v3
 
-      - name: Add yq for reading recipe.yml
+      - name: Add yq (for reading recipe.yml)
         uses: mikefarah/yq@v4.34.2
 
       - name: Gather image data from recipe
         run: |
-          echo "IMAGE_NAME=$(yq '.name' ./${{ matrix.recipe }})" >> $GITHUB_ENV
-          echo "IMAGE_DESCRIPTION=$(yq '.description' ./${{ matrix.recipe }})" >> $GITHUB_ENV
-          echo "FEDORA_MAJOR_VERSION=$(yq '.fedora-version' ./${{ matrix.recipe }})" >> $GITHUB_ENV
-          echo "BASE_IMAGE_URL=$(yq '.base-image' ./${{ matrix.recipe }})" >> $GITHUB_ENV
+          echo "IMAGE_NAME=$(yq '.name' ./config/${{ matrix.recipe }})" >> $GITHUB_ENV
+          echo "IMAGE_DESCRIPTION=$(yq '.description' ./config/${{ matrix.recipe }})" >> $GITHUB_ENV
+          echo "IMAGE_MAJOR_VERSION=$(yq '.image-version' ./config/${{ matrix.recipe }})" >> $GITHUB_ENV
+          echo "BASE_IMAGE_URL=$(yq '.base-image' ./config/${{ matrix.recipe }})" >> $GITHUB_ENV
 
       - name: Get current version
         id: labels
         run: |
-          ver=$(skopeo inspect docker://${{ env.BASE_IMAGE_URL }}:${{ env.FEDORA_MAJOR_VERSION }} | jq -r '.Labels["org.opencontainers.image.version"]')
+          ver=$(skopeo inspect docker://${{ env.BASE_IMAGE_URL }}:${{ env.IMAGE_MAJOR_VERSION }} | jq -r '.Labels["org.opencontainers.image.version"]')
           echo "VERSION=$ver" >> $GITHUB_OUTPUT
 
       - name: Generate tags
@@ -147,7 +140,7 @@ jobs:
           tags: |
             ${{ steps.generate-tags.outputs.alias_tags }}
           build-args: |
-            FEDORA_MAJOR_VERSION=${{ env.FEDORA_MAJOR_VERSION }}
+            IMAGE_MAJOR_VERSION=${{ env.IMAGE_MAJOR_VERSION }}
             BASE_IMAGE_URL=${{ env.BASE_IMAGE_URL }}
             RECIPE=${{ matrix.recipe }}
             IMAGE_REGISTRY=${{ steps.registry_case.outputs.lowercase }}
diff --git a/CHANGELOG.md b/CHANGELOG.md
deleted file mode 100644
index 943a71c4e9..0000000000
--- a/CHANGELOG.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Changelog
-
-## [1.1.0](https://github.com/ublue-os/base/compare/v1.0.0...v1.1.0) (2023-03-03)
-
-
-### Features
-
-* add fedora 38 build ([#45](https://github.com/ublue-os/base/issues/45)) ([69fd4d7](https://github.com/ublue-os/base/commit/69fd4d7a57c5ce39331e47e8dedeb2a2f643190f))
-* add how to review a PR ([#76](https://github.com/ublue-os/base/issues/76)) ([ae2e25b](https://github.com/ublue-os/base/commit/ae2e25b92f5ebebed2fcaad53ecfab651a639d12))
-* ease customization by reading flatpaks and rpms to install from a recipe.yml. ([#79](https://github.com/ublue-os/base/issues/79)) ([a5e90a5](https://github.com/ublue-os/base/commit/a5e90a588f58a938405bf513d1032955be34028e))
-* gha for building / publishing on pr ([#87](https://github.com/ublue-os/base/issues/87)) ([1726d18](https://github.com/ublue-os/base/commit/1726d182ee95ce5eb13f47212799a68b63c5aefc))
-* Install VanillaOS' first-setup ([#55](https://github.com/ublue-os/base/issues/55)) ([43ddf0a](https://github.com/ublue-os/base/commit/43ddf0a123911f9dedc3a76dcfc314a7cb37e871))
-* leave a warning for people to move to new repo ([#99](https://github.com/ublue-os/base/issues/99)) ([ffcb397](https://github.com/ublue-os/base/commit/ffcb3973bd540d679ab033ed94de6336b903e7dd))
-* split flatpak update units into user and system ([#72](https://github.com/ublue-os/base/issues/72)) ([99c15be](https://github.com/ublue-os/base/commit/99c15be6f012cb590891c5ef16b2613dc538d144))
-* swap out custom build for RPM of vanilla-first-setup ([#59](https://github.com/ublue-os/base/issues/59)) ([6927892](https://github.com/ublue-os/base/commit/6927892581dadf8f31419a0d9b070bb7268513ba))
-
-
-### Bug Fixes
-
-* add a warning that we change the flatpak configuration ([#80](https://github.com/ublue-os/base/issues/80)) ([9a349e2](https://github.com/ublue-os/base/commit/9a349e2625791b90c11f640938060344ec3e4bd5))
-* Add vte dependency for first-setup ([#56](https://github.com/ublue-os/base/issues/56)) ([f8917a3](https://github.com/ublue-os/base/commit/f8917a3258196f85b8e3805f5ebcb1c9c0db06a7))
-* allow forks to push to registry with label ([#86](https://github.com/ublue-os/base/issues/86)) ([14b1b7c](https://github.com/ublue-os/base/commit/14b1b7cb044ec616817aa30075609469dcb9986b))
-* artifact upload/extract ([#88](https://github.com/ublue-os/base/issues/88)) ([6590066](https://github.com/ublue-os/base/commit/6590066ebcf72d6c4a56730dd682088db17d7df0))
-* re-tag image ([#92](https://github.com/ublue-os/base/issues/92)) ([a831ce0](https://github.com/ublue-os/base/commit/a831ce00df84d94e2bdb48013f650bcbb5b39568))
-* remove 38 ([#89](https://github.com/ublue-os/base/issues/89)) ([8a6f343](https://github.com/ublue-os/base/commit/8a6f3433ad45b0f9f3da974a691001c02f498fb1))
-* remove 38 builds and fix logo metadata ([#62](https://github.com/ublue-os/base/issues/62)) ([521f0ad](https://github.com/ublue-os/base/commit/521f0adcda598a1bf494d969df375f0c0a03a10c))
-* remove if statements ([#96](https://github.com/ublue-os/base/issues/96)) ([0c7bc17](https://github.com/ublue-os/base/commit/0c7bc17666ae038a0504d24a0e683f724c734527))
-* remove old pr workflow sections ([#98](https://github.com/ublue-os/base/issues/98)) ([4a21580](https://github.com/ublue-os/base/commit/4a21580f4e4d40692449bae61a75a555e8569be1))
-* rename package back to `base` ([#97](https://github.com/ublue-os/base/issues/97)) ([785b8f0](https://github.com/ublue-os/base/commit/785b8f0d8adb8513bbe94b8918bfc0033ee0ca45))
-* restore download artifact step, support multi-line tags ([#90](https://github.com/ublue-os/base/issues/90)) ([c40bddf](https://github.com/ublue-os/base/commit/c40bddfdf39a61545700ecb8123a02abd24a4f8f))
-* update cosign action ([#94](https://github.com/ublue-os/base/issues/94)) ([0aff9ba](https://github.com/ublue-os/base/commit/0aff9bac374c3494f57a360fd4426afe705bfee9))
-
-## 1.0.0 (2023-02-04)
-
-
-### Features
-
-* Add code-of-conduct ([#39](https://github.com/ublue-os/base/issues/39)) ([aab8078](https://github.com/ublue-os/base/commit/aab8078cfdc7d2354e057a0ca4771d3a53d2df4c))
-* add conventional commit linting and release notes generator ([b7820b4](https://github.com/ublue-os/base/commit/b7820b4ba312ca939d0dc977ed9f6a08d135324b))
-* tag PR builds independently from matrix.version, latest, and stable ([b022183](https://github.com/ublue-os/base/commit/b02218386235e6d40a11a48b5b1171e9acf8d1eb))
-
-
-### Bug Fixes
-
-* Don't generate an image when README.md is updated ([#36](https://github.com/ublue-os/base/issues/36)) ([8c170cf](https://github.com/ublue-os/base/commit/8c170cfe89dd306eec0940f4dc50ed245c94bc2b))
-* only generate date tag for main branch ([94aa5bb](https://github.com/ublue-os/base/commit/94aa5bb8df2aac0985d4c9422b19b0c03a3f25b0))
diff --git a/Containerfile b/Containerfile
index dcbc6612b0..084869aa1e 100644
--- a/Containerfile
+++ b/Containerfile
@@ -1,57 +1,47 @@
-# This is the Containerfile for your custom image. 
+# This is the Containerfile for your custom image.
 
-# It takes in the recipe, version, and base image as arguments,
+# Instead of adding RUN statements here, you should consider creating a script
+# in `config/scripts/`. Read more in `modules/script/README.md`
+
+# This Containerfile takes in the recipe, version, and base image as arguments,
 # all of which are provided by build.yml when doing builds
 # in the cloud. The ARGs have default values, but changing those
 # does nothing if the image is built in the cloud.
 
-ARG FEDORA_MAJOR_VERSION=38
-# Warning: changing this might not do anything for you. Read comment above.
+# !! Warning: changing these might not do anything for you. Read comment above.
+ARG IMAGE_MAJOR_VERSION=38
 ARG BASE_IMAGE_URL=ghcr.io/ublue-os/silverblue-main
 
-FROM ${BASE_IMAGE_URL}:${FEDORA_MAJOR_VERSION}
-
-# The default recipe set to the recipe's default filename
-# so that `podman build` should just work for many people.
-ARG RECIPE=./recipe.yml
+FROM ${BASE_IMAGE_URL}:${IMAGE_MAJOR_VERSION}
 
+# The default recipe is set to the recipe's default filename
+# so that `podman build` should just work for most people.
+ARG RECIPE=recipe.yml 
 # The default image registry to write to policy.json and cosign.yaml
 ARG IMAGE_REGISTRY=ghcr.io/ublue-os
 
-# Copy static configurations and component files.
-# Warning: If you want to place anything in "/etc" of the final image, you MUST
-# place them in "./usr/etc" in your repo, so that they're written to "/usr/etc"
-# on the final system. That is the proper directory for "system" configuration
-# templates on immutable Fedora distros, whereas the normal "/etc" is ONLY meant
-# for manual overrides and editing by the machine's admin AFTER installation!
-# See issue #28 (https://github.com/ublue-os/startingpoint/issues/28).
-COPY usr /usr
 
-# Copy public key
 COPY cosign.pub /usr/share/ublue-os/cosign.pub
 
-# Copy the recipe that we're building.
-COPY ${RECIPE} /usr/share/ublue-os/recipe.yml
+# Copy the bling from ublue-os/bling into tmp, to be installed later by the bling module
+# Feel free to remove these lines if you want to speed up image builds and don't want any bling
+COPY --from=ghcr.io/ublue-os/bling:latest /rpms /tmp/bling/rpms
+COPY --from=ghcr.io/ublue-os/bling:latest /files /tmp/bling/files
 
-# Copy nix install script and Universal Blue wallpapers RPM from Bling image
-COPY --from=ghcr.io/ublue-os/bling:latest /rpms/ublue-os-wallpapers-0.1-1.fc38.noarch.rpm /tmp/ublue-os-wallpapers-0.1-1.fc38.noarch.rpm
+# Copy build scripts & configuration
+COPY build.sh /tmp/build.sh
+COPY config /tmp/config/
 
-# Integrate bling justfiles onto image
-COPY --from=ghcr.io/ublue-os/bling:latest /files/usr/share/ublue-os/just /usr/share/ublue-os/just
+# Copy modules
+# The default modules are inside ublue-os/bling
+COPY --from=ghcr.io/ublue-os/bling:latest /modules /tmp/modules/
+# Custom modules overwrite defaults
+COPY modules /tmp/modules/
 
-# Add nix installer if you want to use it
-COPY --from=ghcr.io/ublue-os/bling:latest /files/usr/bin/ublue-nix* /usr/bin
-
-# "yq" used in build.sh and the "setup-flatpaks" just-action to read recipe.yml.
-# Copied from the official container image since it's not available as an RPM.
+# `yq` is used for parsing the yaml configuration
+# It is copied from the official container image since it's not available as an RPM.
 COPY --from=docker.io/mikefarah/yq /usr/bin/yq /usr/bin/yq
 
-# Copy the build script and all custom scripts.
-COPY scripts /tmp/scripts
-
 # Run the build script, then clean up temp files and finalize container build.
-RUN rpm-ostree install /tmp/ublue-os-wallpapers-0.1-1.fc38.noarch.rpm && \
-        chmod +x /tmp/scripts/build.sh && \
-        /tmp/scripts/build.sh && \
-        rm -rf /tmp/* /var/* && \
-        ostree container commit
+RUN chmod +x /tmp/build.sh && /tmp/build.sh && \
+    rm -rf /tmp/* /var/* && ostree container commit
diff --git a/README.md b/README.md
index 380aec5438..418d1613f9 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,10 @@
 # Starting point
 
+> **Warning**
+> Startingpoint was recently rewritten, and this version is considered a "1.0" *semi-*stable release.
+> There are breaking changes between this and the previous version.
+> If you are merging changes from the previous (v0) version, please refer to [the heads-up blog post](https://universal-blue.org/blog/2023/09/02/startingpoint-rewrite-heads-up-what-you-need-to-know/).
+
 [![build-ublue](https://github.com/ublue-os/startingpoint/actions/workflows/build.yml/badge.svg)](https://github.com/ublue-os/startingpoint/actions/workflows/build.yml)
 
 This is a constantly updating template repository for creating [a native container image](https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable) designed to be customized however you want. GitHub will build your image for you, and then host it for you on [ghcr.io](https://github.com/features/packages). You then just tell your computer to boot off of that image. GitHub keeps 90 days worth image backups for you, thanks Microsoft!
@@ -12,6 +17,8 @@ See the [Make Your Own-page in the documentation](https://universal-blue.org/tin
 
 Don't worry, it only requires some basic knowledge about using the terminal and git.
 
+After setup, it is recommended you update this README to describe your custom image.
+
 > **Note**
 > Everywhere in this repository, make sure to replace `ublue-os/startingpoint` with the details of your own repository. Unless you used [`create-ublue-image`](https://github.com/EinoHR/create-ublue-image), in which case the previous repo identifier should already be your repo's details.
 
@@ -20,75 +27,24 @@ Don't worry, it only requires some basic knowledge about using the terminal and
 
 ## Customization
 
-The easiest way to start customizing is by looking at and modifying `recipe.yml`. It's documented using comments and should be pretty easy to understand.
-
-For the base-image field, you can use any other native container image. You will get all the features of that image, plus the ones added here! Check out the [uBlue images list](https://universal-blue.org/images/) to decide what to use!
-
-If you want to add custom configuration files, you can just add them in the `usr/etc/` directory, which is the official OSTree "configuration template" directory. If you need to add other directories, you can look at the Containerfile to see how it's done. Writing to `/etc` or `/var` in Fedora's immutable OSTree-based distros *isn't supported* and will not work, as those are user-managed locations!
-
-> **Note**
-> The configuration files you put in `/usr/etc/` will automatically be applied to your local `/etc/` by `systemd` whenever you rebase an OSTree system or update the image. If a config file in `/etc/` has been *modified* (compared to the same deployment's defaults), then OSTree [won't overwrite it](https://github.com/ostreedev/ostree/blob/16cb47489e582da9c139fee20acdac7079867843/docs/atomic-upgrades.md?plain=1#L76), but the new version will be available in `/usr/etc/`. Run `sudo ostree admin config-diff` to see the difference between `/etc/` and `/usr/etc/` (`man ostree-admin-config-diff` for further documentation).
-
-### Custom build scripts
-
-If you want to execute custom shell scripts or commands in the image build, you shouldn't edit the `scripts/build.sh` or the `Containerfile` directly.
-
-Instead, you should create your own custom shell scripts in the `scripts/` directory (look at the `example.sh`). After creating your scripts, enable them in the `scripts:` section of your `recipe.yml`, within the specific "build stage" category where the scripts are intended to be executed. Alternatively, enable the `autorun.sh` helper script in your recipe to automatically execute your custom scripts.
-
-Read [the README in the `scripts/` directory](https://github.com/ublue-os/startingpoint/blob/main/scripts/README.md) for more information.
-
-### Custom package repositories
-
-If you want to add custom package repositories to your image, you can include them in the `recipe.yml` as a list of URLs under the `rpm.repos:` section. They **must** be proper `.repo` files (such as `https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-38/atim-starship-fedora-38.repo`). In the build process, the `.repo` file will be downloaded and placed inside `/etc/yum.repos.d/` where rpm-ostree can access it.
-
-You can use this to add [COPR repositories](https://copr.fedorainfracloud.org/) to your image.
-COPR is like the Arch User Repository for Fedora, where you can find extra packages that wouldn't otherwise be available. The repositories are community-created, so use them at your own risk. [Read more](https://docs.pagure.org/copr.copr/user_documentation.html)
-
-Tip: You can use the magic string `%FEDORA_VERSION%` in your repo URLs, to automatically refer to the correct repository for your current Fedora version.
-
-If your `.repo` file is not available as a hosted URL and you need to copy it manually, you can upload the file in your github repository or a gist and add the raw link to the file under `rpm.repos:`. Another option in this scenario would be to create a folder for `.repo` files in your repository and add `COPY repos /etc/yum.repos.d/` in the `Containerfile`.
-
-### Building multiple images
+The easiest way to start customizing is by looking at and modifying `config/recipe.yml`. It's documented using comments and should be pretty easy to understand.
 
-You can build multiple images using multiple `recipe.yml` files. They will share the Containerfile and everything else, but things like packages declared in the recipe will be different between the images. For a more robust multibuild setup, you could consider forking from the [ublue-os/main](https://github.com/ublue-os/main/) repo, which was built from the purpose.
+If you want to add custom configuration files, you can just add them in the `/usr/etc/` directory, which is the official OSTree "configuration template" directory and will be applied to `/etc/` on boot. `usr` is copied into your image by default. If you need to add other directories in the root of your image, that can be done in the Containerfile. Writing to `/var/` in the image builds of OSTree-based distros isn't supported and will not work, as that is a local user-managed directory!
 
-In order to build multiple recipes, you need to declare each one below line ~33 in `build.yml`. The files should be in the root of the repository.
+For more information about customization, see [the README in the config directory](config/README.md)
 
-Example: Adding a new recipe called `recipe-2.yml` (snippets from the `matrix` section of `build.yml`)
-
-Before:
-
-```yml
-matrix:
-  recipe:
-    - recipe.yml
-```
-
-After:
-
-```yml
-matrix:
-  recipe:
-    - recipe.yml
-    - recipe-2.yml
-```
-
-### [yafti](https://github.com/ublue-os/yafti/)
-
-`yafti` is the uBlue "first boot" installer. It shows up the first time a user logs into uBlue. By default, the menu also shows up again anytime the image's yafti configuration differs from the user's last encounter, so feel free to expand or modify your custom image's yafti configuration over time. Your users will then see the yafti menu again after the OS update, and will be given a chance to install any new additions.
-
-Its configuration can be found in `/usr/share/ublue-os/firstboot/yafti.yml` of the installed OS. It includes an optional selection of Flatpaks to install, along with a new group that's automatically added for all Flatpaks declared in `recipe.yml`. You can look at what's done in the `yafti.yml` config and modify it to your liking (in the repository, before building the image, since the installed system file is immutable).
-
-If you want to completely disable yafti, simply set the recipe's `firstboot.yafti` flag to `false`, which then removes all yafti-related files and configurations from your final image. The files in `usr/share/ublue-os/firstboot/` are responsible for automatically running yafti at login, and they will *only* be bundled in your image if `yafti` is enabled in your recipe!
+Documentation around making custom images exists / should be written in two separate places:
+* [The Tinkerer's Guide on the website](https://universal-blue.org/tinker/make-your-own/) for general documentation around making custom images, best practices, tutorials, and so on.
+* Inside this repository for documentation specific to the ins and outs of the template (like module documentation), and just some essential guidance on how to make custom images.
 
 ## Installation
 
 > **Warning**
-> This is an experimental feature and should not be used in production, try it in a VM for a while!
+> [This is an experimental feature](https://www.fedoraproject.org/wiki/Changes/OstreeNativeContainerStable) and should not be used in production, try it in a VM for a while!
 
 To rebase an existing Silverblue/Kinoite installation to the latest build:
 
-- First rebase to the image unsigned, to get the proper signing keys and policies installed:
+- First rebase to the unsigned image, to get the proper signing keys and policies installed:
   ```
   sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/startingpoint:latest
   ```
@@ -105,14 +61,13 @@ To rebase an existing Silverblue/Kinoite installation to the latest build:
   systemctl reboot
   ```
 
-
 This repository builds date tags as well, so if you want to rebase to a particular day's build:
 
 ```
 sudo rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/startingpoint:20230403
 ```
 
-This repository by default also supports signing 
+This repository by default also supports signing.
 
 The `latest` tag will automatically point to the latest build. That build will still always use the Fedora version specified in `recipe.yml`, so you won't get accidentally updated to the next major version.
 
@@ -120,40 +75,24 @@ The `latest` tag will automatically point to the latest build. That build will s
 
 This template includes a simple Github Action to build and release an ISO of your image. 
 
-To run the action, simply edit the `boot_menu.yml` by changing all the references to `ublue-os/startingpoint` to your repository. This should trigger the action automatically.
+To run the action, simply edit the `boot_menu.yml` by changing all the references to startingpoint to your repository. This should trigger the action automatically.
 
 The Action uses [isogenerator](https://github.com/ublue-os/isogenerator) and works in a similar manner to the official Universal Blue ISO. If you have any issues, you should first check [the documentation page on installation](https://universal-blue.org/installation/). The ISO is a netinstaller and should always pull the latest version of your image.
 
 Note that this release-iso action is not a replacement for a full-blown release automation like [release-please](https://github.com/googleapis/release-please).
 
-## Just
-
-The `just` task runner is included in `ublue-os/main`-derived images, and we have provided several template commands which help you perform further customization after first boot.
+## `just`
 
-You can merge our template justfiles into your own local configuration. When `just` supports [include directives](https://just.systems/man/en/chapter_52.html), you will instead be able to simply include these paths into your own justfile, without having to copy anything manually.
+The [`just`](https://just.systems/) command runner is included in all `ublue-os/main`-derived images.
 
-Run the following commands when you're logged into the operating system, to merge uBlue's provided configurations into your own user config. (The "touch" command is only necessary on certain shells which won't let you merge into non-existent files.)
-
-```sh
-touch ~/.justfile
-cat /usr/share/ublue-os/just/main.just >> ~/.justfile
-cat /usr/share/ublue-os/just/custom.just >> ~/.justfile
+You need to have a `~/.justfile` with the following contents and `just` aliased to `just --unstable` (default in posix-compatible shells on ublue) to get started with just locally.
 ```
+!include /usr/share/ublue-os/just/main.just
+!include /usr/share/ublue-os/just/nvidia.just
+!include /usr/share/ublue-os/just/custom.just
+```
+Then type `just` to list the just recipes available.
 
-After doing that, you'll be able to run the following commands:
-
-- `just` - Show all tasks, more will be added in the future
-- `just bios` - Reboot into the system bios (Useful for dualbooting)
-- `just changelogs` - Show the changelogs of the pending update
-- Set up distroboxes for the following images:
-  - `just distrobox-boxkit`
-  - `just distrobox-debian`
-  - `just distrobox-opensuse`
-  - `just distrobox-ubuntu`
-- `just setup-flatpaks` - Install all of the flatpaks declared in recipe.yml
-- `just setup-gaming` - Install Steam, Heroic Game Launcher, OBS Studio, Discord, Boatswain, Bottles, and ProtonUp-Qt. MangoHud is installed and enabled by default, hit right Shift-F12 to toggle
-- `just nix-me-up` - Install Nix with dnkmmr69420's Nix Silverblue install script
-- `just update` - Update rpm-ostree, flatpaks, and distroboxes in one command
-
-Check the [just website](https://just.systems) for tips on modifying and adding your own recipes.
+The file `/usr/share/ublue-os/just/custom.just` is intended for the custom just commands (recipes) you wish to include in your image. By default, it includes the justfiles from [`ublue-os/bling`](https://github.com/ublue-os/bling), if you wish to disable that, you need to just remove the line that includes bling.just.
 
+See [the just-page in the Universal Blue documentation](https://universal-blue.org/guide/just/) for more information.
\ No newline at end of file
diff --git a/build.sh b/build.sh
new file mode 100644
index 0000000000..7d33c221a0
--- /dev/null
+++ b/build.sh
@@ -0,0 +1,56 @@
+#!/usr/bin/env bash
+
+# This script executes the modules in order.
+# If you have some custom commands you need to run, you should not put them here.
+# Instead, you should probably include them as custom scripts.
+# Editing this file directly is an unsupported configuration.
+
+# Tell build process to exit if there are any errors.
+set -oue pipefail
+
+export CONFIG_DIRECTORY="/tmp/config"
+RECIPE_FILE="$CONFIG_DIRECTORY/$RECIPE"
+MODULE_DIRECTORY="/tmp/modules"
+
+# https://mikefarah.gitbook.io/yq/usage/tips-and-tricks#yq-in-a-bash-loop
+get_yaml_array() {
+    # creates array $1 with content at key $2 from $3 
+    readarray "$1" < <(echo "$3" | yq -I=0 "$2")
+}
+export -f get_yaml_array # this makes the function available to all modules
+
+# Declare dynamically generated variables as exported
+declare -x IMAGE_NAME BASE_IMAGE OS_VERSION
+
+# Read configuration variables.
+BASE_IMAGE="$(yq '.base-image' "$RECIPE_FILE")"
+IMAGE_NAME="$(yq '.name' "$RECIPE_FILE")"
+
+# Automatically determine which Fedora version we're building.
+OS_VERSION="$(grep -Po '(?<=VERSION_ID=)\d+' /usr/lib/os-release)"
+
+# Welcome.
+echo "Building $IMAGE_NAME from $BASE_IMAGE:$OS_VERSION."
+
+# Run each module
+readarray MODULES < <(yq -o=j -I=0 '.modules[]' "$RECIPE_FILE" )
+
+for MODULE in "${MODULES[@]}"; do
+    TYPE=$(echo "$MODULE" | yq '.type')
+    if [[ "$TYPE" != "null" ]]; then
+        # If type is found, that means that the module config
+        # has been declared inline, and thus is safe to pass to the module
+        echo "=== Launching module of type: $TYPE ==="
+        bash "$MODULE_DIRECTORY/$TYPE/$TYPE.sh" "$MODULE"
+    else
+        # If the type is not found, that means that the module config
+        # is in a separate file, and has to be read from it
+        FILE=$(echo "$MODULE" | yq '.from-file')
+        MODULE_CONFIG=$(yq -o=j -I=0 '.' "$CONFIG_DIRECTORY/$FILE")
+
+        TYPE=$(echo "$MODULE_CONFIG" | yq '.type')
+        echo "=== Launching module of type: $TYPE ==="
+        bash "$MODULE_DIRECTORY/$TYPE/$TYPE.sh" "$MODULE_CONFIG"
+    fi
+    echo "======"
+done
diff --git a/config/README.md b/config/README.md
new file mode 100644
index 0000000000..1e07befff2
--- /dev/null
+++ b/config/README.md
@@ -0,0 +1,31 @@
+# Configuring your image
+
+The main file of your is *the recipe file*. You can have multiple recipe files, and the ones to build are declared in the matrix section of [build.yml](../.github/workflows/build.yml). 
+
+## Basic options
+
+At the top of the recipe, there are four *mandatory* configuration options.
+
+`name:` is the name of the image that is used when rebasing to it. For example, the name "sapphire" would result in the final URL of the container being `ghcr.io/<yourusername>/sapphire`.
+
+`description:` is a short description of your image that will be attached to your image's metadata. 
+
+`base-image:` is the URL of the image your image will be built upon. 
+
+`image-version:` is the version tag of the `base-image` that will be pulled. For example, Universal Blue's images build with Fedora version tags (`38`, `39`), with the `latest` tag for the latest major version, and [many other tags](https://github.com/ublue-os/main/pkgs/container/base-main/versions?filters%5Bversion_type%5D=tagged).
+
+## Modules
+
+The core of startingpoint's configuration is built around the idea of modules. Modules are scripts in the [`../modules`](../modules/) directory that you list out under `modules:` in the recipe. They are executed in order, and can run arbitrary shell commands and write any files.
+
+This repository fetches some useful default modules from [`ublue-os/bling`](https://github.com/ublue-os/bling/), like [`rpm-ostree`](../modules/rpm-ostree) for pseudo-declarative package management, [`bling`](../modules/bling) for pulling extra components from [`ublue-os/bling`](https://github.com/ublue-os/bling), and [`files`](../modules/files) for copying files from the `config/files/` directory into your image. For a comprehensive list of modules and their in-depth documentation, check out [the modules page on the website](https://universal-blue.org/tinker/modules/).
+
+### Including modules from other files and building multiple images
+
+To build multiple images, you need to create another recipe.yml file, which you should name based on what kind of image you want it to build. Then, edit the [`build.yml`](../.github/workflows/build.yml) file. Inside the file, under `jobs: strategy: matrix:`, there's a list of recipe files to build images, which you need to add your new recipe file to. These should be paths to files inside the `config` directory.
+
+Module configuration can be included from other files using the `from-file` syntax. The valye should be a path to a file inside the `config` directory. For example, the following snippet could be used to include the configuration for installing a set of packages common to multiple images.
+```yml
+modules:
+  - from-file: common-packages.yml
+```
\ No newline at end of file
diff --git a/usr/share/ublue-os/firstboot/launcher/autostart.desktop b/config/files/usr/share/ublue-os/firstboot/launcher/autostart.desktop
similarity index 100%
rename from usr/share/ublue-os/firstboot/launcher/autostart.desktop
rename to config/files/usr/share/ublue-os/firstboot/launcher/autostart.desktop
diff --git a/usr/share/ublue-os/firstboot/launcher/autostart.sh b/config/files/usr/share/ublue-os/firstboot/launcher/autostart.sh
similarity index 100%
rename from usr/share/ublue-os/firstboot/launcher/autostart.sh
rename to config/files/usr/share/ublue-os/firstboot/launcher/autostart.sh
diff --git a/usr/share/ublue-os/firstboot/launcher/launcher-flowchart.png b/config/files/usr/share/ublue-os/firstboot/launcher/launcher-flowchart.png
similarity index 100%
rename from usr/share/ublue-os/firstboot/launcher/launcher-flowchart.png
rename to config/files/usr/share/ublue-os/firstboot/launcher/launcher-flowchart.png
diff --git a/usr/share/ublue-os/firstboot/launcher/login-profile.sh b/config/files/usr/share/ublue-os/firstboot/launcher/login-profile.sh
similarity index 100%
rename from usr/share/ublue-os/firstboot/launcher/login-profile.sh
rename to config/files/usr/share/ublue-os/firstboot/launcher/login-profile.sh
diff --git a/usr/share/ublue-os/firstboot/yafti.yml b/config/files/usr/share/ublue-os/firstboot/yafti.yml
similarity index 100%
rename from usr/share/ublue-os/firstboot/yafti.yml
rename to config/files/usr/share/ublue-os/firstboot/yafti.yml
diff --git a/config/files/usr/share/ublue-os/just/custom.just b/config/files/usr/share/ublue-os/just/custom.just
new file mode 100644
index 0000000000..023304a93c
--- /dev/null
+++ b/config/files/usr/share/ublue-os/just/custom.just
@@ -0,0 +1,3 @@
+!include /usr/share/ublue-os/just/bling.just
+
+# Include some of your custom scripts here!
diff --git a/config/recipe.yml b/config/recipe.yml
new file mode 100644
index 0000000000..90d4cb16fa
--- /dev/null
+++ b/config/recipe.yml
@@ -0,0 +1,52 @@
+# image will be published to ghcr.io/<user>/<name>
+name: startingpoint
+# description will be included in the image's metadata
+description: A starting point for further customization of uBlue images. Make your own! https://ublue.it/making-your-own/
+
+# the base image to build on top of (FROM) and the version tag to use
+base-image: ghcr.io/ublue-os/silverblue-main
+image-version: 38 # latest is also supported if you want new updates ASAP
+
+# list of modules, executed in order
+# you can include multiple instances of the same module
+modules:
+
+  - type: files
+    files:
+      - usr: /usr # copy static configurations
+                  # configuration you wish to end up in /etc/ on the booted system should be 
+                  # added into /usr/etc/ as that is the proper "distro" config directory on ostree
+                  # read more in the files module's README
+
+  - type: rpm-ostree
+    repos:
+      # - https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%OS_VERSION%/atim-starship-fedora-%OS_VERSION%.repo
+    install:
+      # - micro
+      # - starship
+    remove:
+      - firefox # default firefox removed in favor of flatpak
+      - firefox-langpacks # langpacks needs to also be removed to prevent dependency problems
+
+  - type: bling # configure what to pull in from ublue-os/bling
+    install:
+      - fonts # selection of common good free fonts
+      - justfiles # add "!include /usr/share/ublue-os/just/bling.just"
+                  # in your custom.just (added by default) or local justfile
+      - nix-installer # shell shortcuts for determinate system's nix installers
+      - ublue-os-wallpapers
+      # - ublue-update # https://github.com/ublue-os/ublue-update
+      # - dconf-update-service # a service unit that updates the dconf db on boot
+      # - devpod # https://devpod.sh/ as an rpm
+
+
+  - type: yafti # if included, yafti and it's dependencies (pip & libadwaita)
+                #  will be installed and set up
+    custom-flatpaks: # this section is optional
+      # - Celluloid: io.github.celluloid_player.Celluloid
+      # - Krita: org.kde.krita
+
+  - type: script
+    scripts:
+      # this sets up the proper policy & signing files for signed images to work
+      - signing.sh
diff --git a/scripts/example.sh b/config/scripts/example.sh
similarity index 100%
rename from scripts/example.sh
rename to config/scripts/example.sh
diff --git a/config/scripts/signing.sh b/config/scripts/signing.sh
new file mode 100644
index 0000000000..fc42de9c90
--- /dev/null
+++ b/config/scripts/signing.sh
@@ -0,0 +1,27 @@
+#!/usr/bin/env bash
+
+# Tell build process to exit if there are any errors.
+set -oue pipefail
+
+echo "Setting up container signing in policy.json and cosign.yaml for $IMAGE_NAME"
+echo "Registry to write: $IMAGE_REGISTRY"
+
+cp /usr/share/ublue-os/cosign.pub /usr/etc/pki/containers/"$IMAGE_NAME".pub
+
+FILE=/usr/etc/containers/policy.json
+
+yq -i -o=j '.transports.docker |= 
+    {"'"$IMAGE_REGISTRY"'": [
+            {
+                "type": "sigstoreSigned",
+                "keyPath": "/usr/etc/pki/containers/'"$IMAGE_NAME"'.pub",
+                "signedIdentity": {
+                    "type": "matchRepository"
+                }
+            }
+        ]
+    }
++ .' "$FILE"
+
+cp /usr/etc/containers/registries.d/ublue-os.yaml /usr/etc/containers/registries.d/"$IMAGE_NAME".yaml
+sed -i "s ghcr.io/ublue-os $IMAGE_REGISTRY g" /usr/etc/containers/registries.d/"$IMAGE_NAME".yaml
\ No newline at end of file
diff --git a/modules/README.md b/modules/README.md
new file mode 100644
index 0000000000..fc9113a41a
--- /dev/null
+++ b/modules/README.md
@@ -0,0 +1,25 @@
+# Making modules
+
+If you want to extend Startingpoint with custom functionality that requires configuration, you should create a module. Modules are scripts in the subdirectories of this directory. The `type:` key in the recipe.yml should be used as both the name of the folder and script, with the script having an additional `.sh` suffix. Creating a custom module with the same name as a default module will override it.
+
+Each module intended for public usage should include a `README.md` file inside it's directory with a short description of the module and documentation for each configuration option.
+
+Modules get only the configuration options given to them in the recipe.yml, not the configuration of other modules or any top-level keys. The configuration is given as the first argument as a single-line json string. You can check out the default modules for examples on how to parse such string using `yq` or `jq`.  
+
+Additionally, each module has access to four environment variables, `CONFIG_DIRECTORY` pointing to the Startingpoint directory in `/usr/share/ublue-os/`, `IMAGE_NAME` being the name of the image as declared in the recipe, `BASE_IMAGE` being the URL of the container image used as the base (FROM) in the image, and `OS_VERSION` being the `VERSION_ID` from `/usr/lib/os-release`.
+
+A helper bash function called `get_yaml_array` is exported from the main build script.
+```bash
+# "$1" is the first cli argument, being the module configuration.
+# If you need to read from some other JSON string, just replace "$1" with "$VARNAME".
+get_yaml_array OUTPUT_VAR_NAME '.yq.key.to.array[]' "$1"
+for THING in "${OUTPUT_VAR_NAME[@]}"; do
+    echo "$THING"
+done
+```
+
+All bash-based modules should start with the following lines to ensure the image builds fail on errors, and that the correct shell is used to run them.
+```bash
+#!/usr/bin/env bash
+set -oue pipefail
+```
\ No newline at end of file
diff --git a/recipe.yml b/recipe.yml
deleted file mode 100644
index e62c20a4f2..0000000000
--- a/recipe.yml
+++ /dev/null
@@ -1,91 +0,0 @@
-# This file can only be edited inside the uBlue image's git repository.
-
-# The image will be at "ghcr.io/yourusername/name".
-name: startingpoint
-
-# The native container image to build on top of.
-# Warning: Non-uBlue images might not work properly, due to missing components.
-base-image: ghcr.io/ublue-os/silverblue-main
-
-# What Fedora version to use. Use an explicit version or `latest`.
-# If you use `latest`, you will be automatically updated to the next major
-# Fedora version, assuming the image you're using as your base container
-# builds with the tag (all uBlue images do this).
-fedora-version: 38
-
-# This description will be visible in the container metadata.
-description: A starting point for further customization of uBlue images. Make your own! https://universal-blue.org/tinker/make-your-own/
-
-# These scripts will be executed during the container build.
-# Place scripts in the "scripts/" dir and put the corresponding filenames here.
-# Any files that aren't listed here won't be executed automatically, which
-# means that you can place "helper" or "library" scripts in the folder too.
-# You can use "autorun.sh" if you want an automatic runner.
-scripts:
-  # "Pre" scripts run very early in the build, immediately after your custom
-  # repos have been imported (so that you can access those repos if necessary).
-  pre:
-    # Automatically runs script files within "scripts/pre/".
-    - autorun.sh
-    # Manually listed scripts.
-    # - example_pre.sh
-
-  # "Post" scripts run at the end of the build process.
-  post:
-    # Automatically runs script files within "scripts/post/".
-    - autorun.sh
-    # Manually listed scripts.
-    # - example_post.sh
-
-# Custom RPM configuration.
-# These changes will be integrated into your custom image at the "system level".
-rpm:
-  # A list of urls of ".repo" files that should be added to your system.
-  # This is the proper way to add custom COPR repos to your image.
-  # Tip: Use `%FEDORA_VERSION%` instead of static Fedora version numbers,
-  # so that your repos automatically use your image's actual Fedora version,
-  # which greatly simplifies future maintenance of your custom recipe.
-  repos:
-    # Example (which also demonstrates version number expansion):
-    # - https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%FEDORA_VERSION%/atim-starship-fedora-%FEDORA_VERSION%.repo
-
-  # These RPMs will be installed from your enabled repositories (Fedora's own
-  # repos, extra "repos" you've added, etc). The installation is automatically
-  # performed via rpm-ostree during the image build, and will be pre-installed
-  # at the "system level" in the final image.
-  install:
-    # Needed for yafti (the first boot installer). Remove if you're not using yafti.
-    - python3-pip
-    # GNOME's GTK4 theme, Libadwaita. Already included in Silverblue, but not
-    # other spins. You can remove if you aren't using yafti, but many native
-    # apps and binaries require it, so it's a good idea to always include it
-    # if you ever download or compile any custom software on your machine.
-    - libadwaita
-    # Add your own below:
-    # Example:
-    # - tilix
-
-  # These RPMs will be removed from the system image. This step happens during
-  # image build, BEFORE installing custom RPMs (from the "rpm.install" category).
-  remove:
-    # Remove the native firefox (from Fedora) in favor of the Flatpak.
-    - firefox
-    - firefox-langpacks
-
-# Configuration for the "first boot" experience, which is available after login.
-firstboot:
-  # Whether to embed "yafti" into the OS image and configure it to autostart,
-  # which is the preferred uBlue "first boot" GUI. Set this to "false" if you've
-  # decided to use a different solution instead.
-  yafti: true
-
-  # These Flatpaks will be suggested for install after user login, via the yafti
-  # "first boot" GUI. Everything below will be merged into the "yafti.yml" config
-  # on build, in a category named "Custom". If you prefer, you can instead remove
-  # everything below and directly edit "yafti.yml" to have more control.
-  # Alternatively, if you've disabled "yafti", you can still install these via
-  # the "just setup-flatpaks" command from our "custom.just" template file.
-  # This is just an example selection:
-  flatpaks:
-    - io.github.celluloid_player.Celluloid
-    - org.kde.krita
diff --git a/scripts/README.md b/scripts/README.md
deleted file mode 100644
index 6c434a1faf..0000000000
--- a/scripts/README.md
+++ /dev/null
@@ -1,55 +0,0 @@
-# Custom scripts
-
-You can add custom scripts to this directory and declare them to be run at build time in the `scripts:` section of `recipe.yml`. Custom scripts can be run at either the `pre:` execution phase right after the custom repositories are added, or at the `post:` phase after all of the automatic build steps.
-
-Your scripts will be given exactly one argument when they are executed, which specifies its precise execution phase (`pre` or `post`). The primary purpose of this argument is to streamline the reuse of scripts for multiple stages. This argument is provided for both manually declared scripts and scripts ran by `autorun.sh`.
-
-## Creating a script
-
-Look at `example.sh` for an example shell script. You can rename and copy the file for your own purposes. In order for the script to be executed, either move it to `scripts/pre/` or `scripts/post/` (if using `autorun.sh`) or declare it in the `recipe.yml`.
-
-All commands from RPMs you've declared in the `recipe.yml` should be available when running scripts at the `post` execution phase.
-
-When creating a script, please make sure
-
-- ...its filename ends with `.sh`.
-  - This follows convention for (especially bash) shell scripts.
-  - `autorun.sh` only executes files that match `*.sh`.
-- ...it starts with a [shebang](<https://en.wikipedia.org/wiki/Shebang_(Unix)>) like `#!/usr/bin/env bash`.
-  - This ensures the script is ran with the correct interpreter / shell.
-- ...it contains the command `set -oue pipefail` near the start.
-  - This will make the image build fail if your script fails. If you do not care if your script works or not, you can omit this line.
-
-## `autorun.sh`
-
-`autorun.sh` is a script that automatically runs all scripts in the folders `scripts/pre/` and `scripts/post/` at the correct execution phases. It is enabled by default, but you can disable it by removing it from `recipe.yml`. Manually listed scripts can be combined with `autorun.sh`.
-
-There are a few rules, which aim to simplify your script management:
-
-- `autorun.sh` will only execute scripts at the FIRST level within the directory, which
-  means that anything stored in e.g. `scripts/pre/deeperfolder/` will NOT execute.
-  This is intentional, so that you can store libraries and helper scripts
-  within subdirectories.
-- You script directories and the scripts within them can be symlinks, to allow
-  easy reuse of scripts. For example, if you want the same scripts to execute
-  during both the `pre` and `post` stages, you could simply symlink individual
-  scripts or the entire `pre` and `post` directories to each other. However,
-  remember to only use RELATIVE symlinks, to ensure that the links work
-  properly. For example, `ln -s ../pre/foo.sh scripts/post/foo.sh`.
-- All scripts execute in a numerically and alphabetically sorted order, which
-  allows you to easily control the execution order of your scripts. If it's
-  important that they execute in a specific order, then you should give them
-  appropriate names. For example, `05-foo.s` would always execute before
-  another script named `99-bar.sh`. It's recommended to use zero-padded,
-  numerical prefixes when you want to specify the execution order.
-- The manually listed scripts in `recipe.yml` should
-  be stored directly within `scripts/`, or in a custom subdirectory that
-  doesn't match any of the execution phases. For example, you could
-  set the `pre:` section of `recipe.yml` to execute both `autorun.sh`
-  and `fizzwidget/something.sh`, and then place a bunch of auto-executed
-  scripts under `scripts/pre/` for the autorunner. This makes it very simple
-  to reuse common scripts between multiple different `recipe.yml` files,
-  while also having some scripts be specific to different `recipe.yml`s.
-- You can safely specify `autorun.sh` as a script in `recipe.yml`,
-  even if the special directories don't exist or don't contain any
-  scripts. It will gracefully skip the processing if there's nothing to do.
diff --git a/scripts/autorun.sh b/scripts/autorun.sh
deleted file mode 100644
index 3b9b1c2c01..0000000000
--- a/scripts/autorun.sh
+++ /dev/null
@@ -1,48 +0,0 @@
-#!/usr/bin/env bash
-
-# Tell this script to exit if there are any errors.
-set -oue pipefail
-
-#
-# AUTORUN:
-#
-# This script simplifies your "recipe.yml" management whenever you simply want
-# to "run everything automatically" based on whatever script files exist on disk.
-#
-
-# Helper functions.
-yell() { echo "${0}: ${*}"; }
-abort() { yell "${*}"; exit 0; }
-die() { yell "${*}"; exit 1; }
-
-# Determine which directory and script category we're executing under.
-SCRIPT_DIR="$(dirname -- "${BASH_SOURCE[0]}")"
-SCRIPT_MODE="${1:-}"
-if [[ -z "${SCRIPT_MODE}" ]]; then
-    die "Missing script mode argument."
-fi
-
-# Ensure that a "scripts/" sub-directory exists for the "script category".
-# Note that symlinks to other directories will be accepted by the `-d` check.
-RUN_DIR="${SCRIPT_DIR}/${SCRIPT_MODE}"
-if [[ ! -d "${RUN_DIR}" ]]; then
-    abort "Nothing to do, since \"${RUN_DIR}\" doesn't exist."
-fi
-
-# Generate a numerically sorted array of all scripts (or symlinks to scripts),
-# without traversing into deeper subdirectories (to allow the user to store
-# helper libraries in subfolders without accidental execution). Sorting is
-# necessary for manually controlling the execution order via numeric prefixes.
-mapfile -t buildscripts < <(find -L "${RUN_DIR}" -maxdepth 1 -type f -name "*.sh" | sort -n)
-
-# Exit if there aren't any scripts in the directory.
-if [[ ${#buildscripts[@]} -eq 0 ]]; then
-    abort "Nothing to do, since \"${RUN_DIR}\" doesn't contain any scripts in its top-level directory."
-fi
-
-# Now simply execute all of the discovered scripts, and provide the name of the
-# current "script category" as an argument, to match the behavior of "build.sh".
-for script in "${buildscripts[@]}"; do
-    echo "[autorun.sh] Running [${SCRIPT_MODE}]: ${script}"
-    "$script" "${SCRIPT_MODE}"
-done
diff --git a/scripts/build.sh b/scripts/build.sh
deleted file mode 100644
index c5d43fffbf..0000000000
--- a/scripts/build.sh
+++ /dev/null
@@ -1,138 +0,0 @@
-#!/usr/bin/env bash
-
-# Tell build process to exit if there are any errors.
-set -oue pipefail
-
-# Helper functions.
-RECIPE_FILE="/usr/share/ublue-os/recipe.yml"
-get_yaml_array() {
-    mapfile -t "${1}" < <(yq -- "${2}" "${RECIPE_FILE}")
-}
-get_yaml_string() {
-    yq -- "${1}" "${RECIPE_FILE}"
-}
-
-# Automatically determine which Fedora version we're building.
-FEDORA_VERSION="$(cat /usr/lib/os-release | grep -Po '(?<=VERSION_ID=)\d+')"
-
-# Read configuration variables.
-BASE_IMAGE="$(get_yaml_string '.base-image')"
-YAFTI_ENABLED="$(get_yaml_string '.firstboot.yafti')"
-
-# Welcome.
-echo "Building custom Fedora ${FEDORA_VERSION} from image: \"${BASE_IMAGE}\"."
-
-# Add custom repos.
-get_yaml_array repos '.rpm.repos[]'
-if [[ ${#repos[@]} -gt 0 ]]; then
-    echo "-- Adding repos defined in recipe.yml --"
-    for repo in "${repos[@]}"; do
-        repo="${repo//%FEDORA_VERSION%/${FEDORA_VERSION}}"
-        wget "${repo}" -P "/etc/yum.repos.d/"
-    done
-    echo "---"
-fi
-
-# Ensure that all script files are executable.
-find /tmp/scripts -type f -exec chmod +x {} \;
-
-# Run "pre" scripts.
-run_scripts() {
-    script_mode="$1"
-    get_yaml_array buildscripts ".scripts.${script_mode}[]"
-    if [[ ${#buildscripts[@]} -gt 0 ]]; then
-        echo "-- Running [${script_mode}] scripts defined in recipe.yml --"
-        for script in "${buildscripts[@]}"; do
-            echo "Running [${script_mode}]: ${script}"
-            "/tmp/scripts/${script}" "${script_mode}"
-        done
-        echo "---"
-    fi
-}
-run_scripts "pre"
-
-# Install RPMs.
-get_yaml_array install_rpms '.rpm.install[]'
-if [[ ${#install_rpms[@]} -gt 0 ]]; then
-    echo "-- Installing RPMs defined in recipe.yml --"
-    echo "Installing: ${install_rpms[@]}"
-    rpm-ostree install "${install_rpms[@]}"
-    echo "---"
-fi
-
-# Remove RPMs.
-get_yaml_array remove_rpms '.rpm.remove[]'
-if [[ ${#remove_rpms[@]} -gt 0 ]]; then
-    echo "-- Removing RPMs defined in recipe.yml --"
-    echo "Removing: ${remove_rpms[@]}"
-    rpm-ostree override remove "${remove_rpms[@]}"
-    echo "---"
-fi
-
-# Toggle yafti, which provides the "first boot" experience, https://github.com/ublue-os/yafti.
-FIRSTBOOT_DATA="/usr/share/ublue-os/firstboot"
-FIRSTBOOT_LINK="/usr/etc/profile.d/ublue-firstboot.sh"
-if [[ "${YAFTI_ENABLED}" == "true" ]]; then
-    echo "-- firstboot: Installing and enabling \"yafti\" --"
-    pip install --prefix=/usr yafti
-    # Create symlink to our profile script, which creates the per-user "autorun yafti" links.
-    mkdir -p "$(dirname "${FIRSTBOOT_LINK}")"
-    ln -s "${FIRSTBOOT_DATA}/launcher/login-profile.sh" "${FIRSTBOOT_LINK}"
-else
-    echo "-- firstboot: Removing all \"firstboot\" components --"
-    # Removes the script symlink that creates the per-user autostart symlinks.
-    # We must forcibly remove this here, in case it was added by an upstream image.
-    rm -f "${FIRSTBOOT_LINK}"
-    # Remove all of the launcher-scripts and yafti config, to de-clutter image and
-    # ensure it can't run by accident due to lingering symlinks or upstream image.
-    rm -rf "${FIRSTBOOT_DATA}"
-fi
-
-# Add a new yafti "package group" called Custom, for the packages defined in recipe.yml.
-# Only adds the package group if yafti is enabled and Flatpaks are defined in the recipe.
-if [[ "${YAFTI_ENABLED}" == "true" ]]; then
-    YAFTI_FILE="${FIRSTBOOT_DATA}/yafti.yml"
-    get_yaml_array flatpaks '.firstboot.flatpaks[]'
-    if [[ ${#flatpaks[@]} -gt 0 ]]; then
-        echo "-- yafti: Adding Flatpaks defined in recipe.yml --"
-        yq -i '.screens.applications.values.groups.Custom.description = "Flatpaks suggested by the image maintainer."' "${YAFTI_FILE}"
-        yq -i '.screens.applications.values.groups.Custom.default = true' "${YAFTI_FILE}"
-        for pkg in "${flatpaks[@]}"; do
-            echo "Adding to yafti: ${pkg}"
-            yq -i ".screens.applications.values.groups.Custom.packages += [{\"${pkg}\": \"${pkg}\"}]" "${YAFTI_FILE}"
-        done
-        echo "---"
-    fi
-fi
-
-# Setup container signing
-echo "Setup container signing in policy.json and cosign.yaml"
-echo "Registry to write: $IMAGE_REGISTRY"
-
-# Copy Name
-NAME=$(get_yaml_string '.name')
-cp /usr/share/ublue-os/cosign.pub /usr/etc/pki/containers/"$NAME".pub
-
-# Work around the fact that jq doesn't have an "inplace" option
-FILE=/usr/etc/containers/policy.json
-TMP=/tmp/policy.json
-
-jq '.transports.docker |= 
-    {"'"$IMAGE_REGISTRY"'": [
-            {
-                "type": "sigstoreSigned",
-                "keyPath": "/usr/etc/pki/containers/'"$NAME"'.pub",
-                "signedIdentity": {
-                    "type": "matchRepository"
-                }
-            }
-        ]
-    }
-+ .' $FILE > $TMP
-mv -f $TMP $FILE
-
-cp /usr/etc/containers/registries.d/ublue-os.yaml /usr/etc/containers/registries.d/"$NAME".yaml
-sed -i "s ghcr.io/ublue-os $IMAGE_REGISTRY g" /usr/etc/containers/registries.d/"$NAME".yaml
-
-# Run "post" scripts.
-run_scripts "post"
diff --git a/scripts/post/.gitkeep b/scripts/post/.gitkeep
deleted file mode 100644
index e69de29bb2..0000000000
diff --git a/scripts/pre/.gitkeep b/scripts/pre/.gitkeep
deleted file mode 100644
index e69de29bb2..0000000000
diff --git a/usr/bin/.gitkeep b/usr/bin/.gitkeep
deleted file mode 100644
index e69de29bb2..0000000000
diff --git a/usr/share/ublue-os/just/custom.just b/usr/share/ublue-os/just/custom.just
deleted file mode 100644
index 80387faa29..0000000000
--- a/usr/share/ublue-os/just/custom.just
+++ /dev/null
@@ -1,13 +0,0 @@
-!include /usr/share/ublue-os/just/bling.just
-
-# Install all flatpaks defined in recipe.yml
-setup-flatpaks:
-  #!/usr/bin/env bash
-  echo 'Installing flatpaks from the ublue recipe ...'
-  flatpaks=$(yq -- '.firstboot.flatpaks[]' "/usr/share/ublue-os/recipe.yml")
-  for pkg in $flatpaks; do \
-      echo "Installing: ${pkg}" && \
-      flatpak install --user --noninteractive flathub $pkg; \
-  done
-
-# Include some of your custom scripts here!