Forem: jsph

SEO and LLM Discoverability for Phoenix Web Apps

jsph — Thu, 16 Apr 2026 02:56:45 +0000

How I set up SEO and LLM discoverability for my Phoenix app

I recently shipped the discoverability layer for Wish List Palace, a free wish list app for coordinating family gift giving. This post covers everything I put in place: standard search engine SEO, structured data, and the newer llms.txt standard for getting picked up by AI tools and training crawlers. I hope people stumble upon this site. People who for whatever reason have a need for it, but I also definitely didn't want to buy ads or try to exploit SEO. The wishlist app space is already super crowded so I don't think any of those strategies would help much but making it easier for crawlers and LLMs to understand what the app is and what it does was the goal.

The stack is Phoenix LiveView, but most of this applies to any web app. Also LiveView isn't really necessary for what follows since it's mostly about setting up certain static assets to serve.

Standard SEO foundations

Meta and Open Graph tags

Every page gets a full set of tags in <head>:

<meta name="description"> — the snippet shown in Google results
Open Graph tags (og:title, og:description, og:type, og:url, og:image) — controls the preview card when a URL is shared on WhatsApp, iMessage, Slack, etc.
Twitter Card tags — same idea for Twitter/X
<link rel="canonical"> — prevents duplicate content issues when a CDN like Cloudflare serves cached variants at different URLs

In Phoenix, the root layout sets sensible defaults. Individual LiveViews can override them in mount/3 via assigns:

{:ok, assign(socket,
  page_title: "How It Works — Wish List Palace",
  page_description: "Step-by-step guide to creating lists, sharing, and claiming gifts.",
  canonical_url: "https://wishlistpalace.com/how-it-works"
)}

One gotcha: og:image is commonly set to an SVG logo, but WhatsApp, Twitter/X, and iMessage silently ignore SVGs. You need a PNG or JPG (1200×630px is the recommended size) to get actual preview images in link cards.

robots.txt

The classic way to let crawlers (who want to obey your suggestions, at least) know what's the deal with your web app is yourdomain.com/robots.txt. The first thing to do is disallow authenticated and admin routes so crawlers don't waste crawl budget on pages they can't access anyway. Since wishlistpalace has users with accounts and you have to be authenticated to see your own lists, there is no need for robots to visit /lists since they are not authenticated users.

Explicitly allow the public pages and LLM files. Basically whatever call to action stuff you have you want the robots to check out. Also I added a /how-it-works page to give an explanation of the basics. In theory this could be used by an LLM to tell a user how to use the site.

User-agent: *
Allow: /
Allow: /how-it-works
Allow: /llms.txt
Allow: /llms-full.txt
Disallow: /home
Disallow: /lists
Disallow: /claimed
Disallow: /admin
Disallow: /auth

Sitemap: https://wishlistpalace.com/sitemap.xml

These days if you want traffic to your site, not only do you want search engine crawlers to pick you up but also it would be cool if LLMs suggested people use your site. That's of course easier said than done, but it can't hurt to get some positive impression of your site in the training sets being collected. The explicit Allow lines matter for training crawlers like Common Crawl (CCBot), which tend to be conservative. More on this below.

sitemap.xml

A static sitemap covering every public indexable page. In Phoenix this lives in priv/static/sitemap.xml and gets served by Plug.Static. I give the how-it-works page a higher priority than register/sign-in since it has real content worth ranking:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://wishlistpalace.com/</loc>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://wishlistpalace.com/how-it-works</loc>
    <priority>0.8</priority>
  </url>
  <url>
    <loc>https://wishlistpalace.com/register</loc>
    <priority>0.5</priority>
  </url>
  <url>
    <loc>https://wishlistpalace.com/sign-in</loc>
    <priority>0.3</priority>
  </url>
</urlset>

Submit this to Google Search Console and Bing Webmaster Tools. Bing is maybe also worth it because the alternative search engines often source crawl results from Bing in some form or fashion.

JSON-LD structured data

Schema.org markup embedded in every page as a <script type="application/ld+json"> tag tells Google explicitly what kind of thing this is. For a web app, SoftwareApplication is the right type:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Wish List Palace",
  "url": "https://wishlistpalace.com",
  "applicationCategory": "LifestyleApplication",
  "operatingSystem": "Web",
  "description": "Coordinate family gift giving without spoiling surprises. Share wish lists, claim items secretly, and avoid duplicate gifts.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}

This can unlock app-style rich results in search. It's also increasingly read by AI-powered search tools as a structured signal about what a site does. If you later add a review system, an aggregateRating property qualifies you for star ratings in search results.

LLM discoverability with llms.txt

The llmstxt.org standard is a convention for helping LLM-powered tools — AI chatbots, AI search engines, coding assistants — understand what a site is and how to use it. The idea is simple: serve a markdown file at /llms.txt that summarises the site and links to deeper content.

I serve two files:

/llms.txt — the index, following the spec format:

# Wish List Palace

> Wish List Palace is a free wish list app for families and friends...

## Docs

- [Full guide](https://wishlistpalace.com/llms-full.txt): Complete guide covering all features

## Pages

- [How it works](https://wishlistpalace.com/how-it-works): Step-by-step walkthrough
- [Home](https://wishlistpalace.com/): Landing page
- [Register](https://wishlistpalace.com/register): Create a free account

/llms-full.txt — a comprehensive markdown guide covering every feature: creating lists, adding items (with links, priorities, and tags), sharing, and how gift claiming works privately.

In Phoenix, these are static files in priv/static/. The only configuration needed is adding them to the static_paths/0 allowlist so Plug.Static serves them:

def static_paths,
  do: ~w(assets fonts images favicon.ico robots.txt sitemap.xml llms.txt llms-full.txt)

Search ranking strategy

Here is generally how I am thinking about improving the ranking of wishlistpalace. Trying to get ranked on queries like "wishlist app" which are dominated by Amazon, MyRegistry, and Giftster is probably not worth it on my budget. These sites have years of domain authority and thousands of backlinks. Competing directly for those terms is probably worthless, even in the long run.

Instead I kind of want to show up for the long tail of queries. These have far less competition and are better intent-matched:

"wish list app where others can claim gifts"
"how to share a christmas list without spoilers"
"wish list app no duplicates"
"alternative to amazon wish list"

Someone searching those phrases has exactly the problem this app solves. Ranking page 1 for five specific long-tail queries beats ranking page 4 for a head term.

I can hope to have some domain authority built through backlinks from trusted external sites over time. One-time directory listings (AlternativeTo, SaaSHub, Product Hunt) and community posts (Hacker News Show HN, relevant subreddits) are what I aim for though I'm waiting to finish some more features before engaging with those. But even a few backlinks over time can compound.

Github Actions for Phoenix App Deployment to Hetzner

jsph — Sat, 11 Apr 2026 03:45:18 +0000

Recently I started hosting wishlist palace on a Hetzner CX23 VPS (that has 4 GB of ram and 2 vcpu). At work usually I package software into a container before deploying it. One of the reasons I chose Elixir and Phoenix as the tech stack for wishlist palace is that I wanted to try out mix releases which prepare binaries.

OS and chip architecture

Originally I was just going to compile on my local machine (A thinkpad T480) and upload to the server. But this didn't work because the VPS I had provisioned was running ubuntu 24.04 LTS and my local machine is on EndevousOS (a flavor of Arch by-the-way). So rather than local build and push, I opted to get claude to build a series of github actions that would build on a worker that was running ubuntu. This had the added benefit of basically completely setting up a basic CI loop so that when a release is cut we build a new binary and deploy it on the server.

Elixir's mix release creates a self-contained binary that bundles the Erlang VM along with the compiled application. The server needs no Elixir or Erlang installed (just a matching Linux architecture which as I said before tripped me up a bit).

Release Strategy

The release is pushed to the server with rsync, which only transfers changed files:

rsync -avz --delete _build/prod/rel/wish_list/ deploy@$VPS_IP:/opt/wish_list/

Process management with `systemd`

The phoenix app runs as a systemd service so one uses systemctl to interact with processes under its control. In the future I might setup something more like a blue-green deploy but for now I just restart the service after rsync updates the binary. The github action below restarts the service to pick up the changes.

Migrations

Of course I also have a postgreSQL database running on the VPS so I need to do migrations from time to time. Migrations are run via the release's eval command, calling a specific release command within my application code and run directly against the production database. For me that looks like

/opt/wish_list/bin/wish_list eval "WishListDomain.Release.migrate()"

CI/CD: GitHub Actions on Release

Deployments are triggered by publishing a GitHub Release. I like to have some testing before deploy just to catch catastrophic failures on my part so the first step runs tests. Then if tests are green we can build, compile, deploy, migrate, and restart the service.

Job 1 — Test

Spins up a Postgres 16 service container, installs Elixir 1.19 / OTP 27, runs migrations, and executes the test suite.

  name: Deploy

  on:
    release:
      types: [published]

  jobs:
    test:
      name: Test
      runs-on: ubuntu-24.04

      services:
        postgres:
          image: postgres:16
          env:
            POSTGRES_USER: postgres
            POSTGRES_PASSWORD: postgres
            POSTGRES_DB: wish_list_test
          ports:
            - 5432:5432
          options: >-
            --health-cmd pg_isready
            --health-interval 10s
            --health-timeout 5s
            --health-retries 5

      env:
        MIX_ENV: test
        DATABASE_URL: ecto://postgres:postgres@localhost/wish_list_test
        TOKEN_SIGNING_SECRET: test_token_signing_secret

      steps:
        - uses: actions/checkout@v4
        - name: Set up Elixir
          uses: erlef/setup-beam@v1
          with:
            elixir-version: "1.19"
            otp-version: "27"
        - name: Install deps
          run: mix deps.get
        - name: Compile
          run: mix compile --warnings-as-errors
        - name: Run migrations
          run: mix ecto.migrate --repo WishListDomain.Repo
        - name: Run tests
          run: mix test

Job 2 — Build & Deploy (runs only after test passes)

Builds the production release, opens an SSH connection to the Hetzner VPS, rsyncs the release binary, runs migrations, restarts the systemd service, and verifies it came up:

  build-and-deploy:
      name: Build & Deploy
      runs-on: ubuntu-24.04
      needs: test
      env:
        MIX_ENV: prod

      steps:
        - uses: actions/checkout@v4
        - name: Set up Elixir
          uses: erlef/setup-beam@v1
          with:
            elixir-version: "1.19"
            otp-version: "27"

        - name: Install deps
          run: mix deps.get --only prod

        - name: Build assets
          run: cd apps/wish_list_web && mix assets.deploy

        - name: Build release
          run: mix release wish_list

        - name: Set up SSH
          run: |
            mkdir -p ~/.ssh
            echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
            chmod 600 ~/.ssh/id_ed25519
            ssh-keyscan -H ${{ secrets.VPS_IP }} >> ~/.ssh/known_hosts

        - name: Sync release to VPS
          run: |
            rsync -az --delete \
              _build/prod/rel/wish_list/ \
              deploy@${{ secrets.VPS_IP }}:/opt/wish_list/

        - name: Run migrations
          run: |
            ssh deploy@${{ secrets.VPS_IP }} \
              'set -a && source /etc/wish_list.env && set +a && /opt/wish_list/bin/wish_list eval
  "WishListDomain.Release.migrate()"'

        - name: Restart service
          run: |
            ssh deploy@${{ secrets.VPS_IP }} \
              'sudo systemctl restart wish_list'

        - name: Verify service is running
          run: |
            ssh deploy@${{ secrets.VPS_IP }} \
              'sudo systemctl is-active wish_list'

Two GitHub Actions secrets are required: SSH_PRIVATE_KEY (the private key for the deploy user) and VPS_IP (the server's IP address).

How to Protect Your New VPS

jsph — Sat, 04 Apr 2026 04:03:29 +0000

I was very intimitaded about using a VPS outside a VPC my web apps. I had never used a stand alone VPS without some kind of walled garden around it. At work everything is usually behind a VPC. And I have always worked with awesome security people to double check things! I don't have to worry so much about bots or people constantly trying to exploit my service (of course we follow guidence from our excellent security colleagues). But when you turn on your new VPS it immediately can be discovered and bots will immediately try to exploit vulnerabilities.

Recently I launched wishlistpalace.com which is running on a Hetzner VPS and I have come to find out that things are not quite a dire or dangerous as I had thought.

SSH vulnerabilities

One flavor of exploit that bots try against your VPS is to try a bunch of passwords to try to be able to ssh into your new VPS and do whatever (maybe start mining bitcoin or installing malware). Thankfully, VPS providers don't just spin up your box with weak passwords and call it a day. In fact it's even better than that on Hetzner. They let you explicit disable ssh password authentication so this exploit simply won't happen to your new box.

But then you might ask, how do I get into my box then? With the key of course. By default the setup wizard on the Hetzner site for new VPS asks you to provide a public ssh key. You can use

ssh-keygen -t ed25519 -f ~/.ssh/name_of_key -C "your new hetzner box"

to generate a public and private key pair. Then during the setup flow you upload the PUBLIC key.

Later once your box is up you will be able to get the IP for the VPS. Shelling into your box can be made super simple by setting up your ssh config. Add an entry to ~/.ssh/config so SSH uses it automatically:

Host someNameOfYourBox
    HostName <your-vps-ip>
    User root
    IdentityFile ~/.ssh/name_of_key

Just replace the place holder values above of course!

Bot protection

Another probably unfounded fear was that as soon as I turned on my VPS there would be a DDoS or some other overwhelm attack. That I thought this probably means I think a little too highly of myself sure there will be pokes at the new IP but probably not a DDoS right out of the gate. Never-the-less I learned about a few bot protection measures.

Cloudflare

This is probably obvious to most, but if you are really worried about bots, the cloudflare is the way the go. And they have a free tier. I won't list the full instructions on how to setup here, but there are lots of good tutorials I found on line, and Claude was helpful in getting this setup.

I chose also to use nginx in front of my app so I needed to configure the handshake between cloudflare and nginx.

`fail2ban`

Something you can run on the new VPS is fail2ban which monitors login attempts and temporarily bans IPs that fail too many times. It's kind of fun to use because after a few days you can the thousands of failed attempts to get into your machine from bots.

The VPS I set up is using Ubuntu 24.04 LTS and setting up fail2ban is as simple as

apt install fail2ban

After about a week after I started the VPS here's what I see when I check in on fail2ban with sudo fail2ban-client status sshd to check attacks against ssh.

Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     3487
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 0
   |- Total banned:     164
   `- Banned IP list:

Wow! I'm so thankful bots wanted to try to shell into my VPS!

Firewall

Ubuntu has a firewall utility called ufw and is a quick way to help protect the service you want to run on the VPS. After all I wanted to host wishlist palace the application on the VPS that was the whole point. I chose Elixir's Phoenix framework as the web service part of the app and it exposes the port 4000. But as soon as I spin it up it is possible for people to try some exploit against this port.

But with a firewall and using cloudflare and nginx we can really lock down direct access to the app. The desired state would ensure that the only traffic to the app has to travel through our protective layer above, i.e., cloudflare and nginx.

graph LR
  User -->|":443 HTTPS"| Cloudflare
  Cloudflare -->|":443 HTTPS"| nginx
  nginx -->|":4000 HTTP"| Phoenix
  nginx -->|":80 HTTP redirect"| Cloudflare

To achieve this we can setup the firewall to limit to only the ports we need for this desired access pattern. With a few invocations of ufw you can lock access down. But it is important to leave the ssh port open so you can get back in.

ufw allow 22    # SSH — do this FIRST or you'll lock yourself out
ufw allow 80    # HTTP — needed for Certbot's verification step
ufw allow 443   # HTTPS — your app's public port
ufw enable
ufw status      # confirm rules are active

This basically sets up an allow list then locks every other port down.

Maybe not so scary after all

That's all I did in the first week of having my VPS and so far it hasn't crashed so maybe I was wrong to be worried. I have no doubt there are other important security techniques I need to learn about but I wanted to share this setup.

I think I might follow up with more details about the cloudflare nginx setup in another post.

How to Use Augmented Coding to Build a Web App

jsph — Wed, 01 Apr 2026 02:59:12 +0000

I recently launched wishlist palace which is a web app to help share information with friends and family about birthday lists and christmas lists. This app is my first exploration into using Augemented coding (which is a term I prefer over vibe coding).

When I first heard of vibe coding, I wasn't particularly interested in engaging with it as a mode of production I use myself. I enjoy the problem solving aspect of software engineering and at face value much of that process falls into the lap of the LLM when doing vibe coding. And it's not only the solution of the problem at hand that is of interest to me but directly engaging and phrasing that problem in the formalisms of programming languages scartches an itch in the same way I image poets feel when they want to express themselves in poetry. The trouble with the situation we (as tech folk) are in now is that the terms (like vibe and augmented coding) are highly overloaded and are used to described vastly different development cycles from the one shot prompt of 100 words attempting to get a polished app to the very detailed prompt to obtain the 10 line fix you requested in a few hundred words.

Accompanying these observations are claims that LLMs are unlocking (insert large integer) times speed up in product development and claims that the landscape of software development has fundamentally shifted and there will be no jobs and we are on the cusp of fully automating the production of software for all use cases. Then there are people I respect deeply saying they will never touch LLMs and will categorically reject any code which smells as if it was touched by generative AI. Not to mention important ethical considerations that have been raised about AI use. All this conflicting information has left me with a bit of confusion.

Rather than try to parse what is globally true about LLMs and their use to generate software, I thought I'd see how I could use to solve a problem I have (and a somewhat mundane problem at that). Then with this as at least one data point I can start to see where I land in the vast spectrum of AI/LLM assessment.

Choosing frameworks

The choice of tech stack will have a big impact on what you can expect from the LLM. For wishlist palace I went with technologies I have some knowledge of and also that I like the philosophy of

Elixir mix build automation tool and functional programming
Ash Framework for domain modeling and also for it's ash_authentication library
Pheonix for the web server and to use it's LiveView for realtime updates to wish lists

In theory an LLM could generate for you a bespoke programming language for your project. But just as humans often choose to leverage what has already worked because they can benefit from what other's have developed so too there is obvious benefit of choosing what has been proven to work when doing augmented coding. Since the popularity of a framework or language is a proxy for how much training data the LLM had access to, I think it's also important to make a choice based on systems you like to work with. For me that's functional programming. I have learned some elixir doing some side projects but I've never released a web app in the language. I chose elixir because I am intereseted in the BEAM virtual machine and it's cool features like hot code loading and it's concurrency features. So I was a bit familiar with Elixir and have used the webframework Phoenix a bit before (but never in production) so they were reasonable candidates for the prospect of evaluating the generated output from the LLM.

There is a big difference between generating code in a language or framework that you have close to zero context yourself in and generating it in a context in which you have deep knowledge. In my professional work I use python primarily and work on backend systems. I feel much more confident in that scenario when evaluating LLM generated plans and code given that I just have much more experience building with. I have much less experience building front end features. I'm still a bit scared to modify css files and JS is not a strong suite of mine. So I knew I was going to have a harder time evaluating the quality of the front end components generated by an LLM. But Pheonix has HTML HEEx (HTML + Embedded Elixir) which is not such a stretch for me, I do know some HTML (certainly I don't know all of the features of HTML though).

Start with core data structures

A strategy I think is helpful is to first build the core data structures and transformations on these data strucutres that you app will require. This way you can reason about if you have the right data strucutures before jumping into designing the user experience.

This strategy fits well with the philosophy of Ash Framework which is well suited to domain driven design. I like Ash because it gives you an easy way to declare what the shape of the data looks like (as attributes), the transformations that can be applied to them (as actions), and how it will be persisted (with Ash's Repo abstraction).

So I built first the concepts of List and Item which are funnily enough very similar to the classic TODO list app that is usually the subject of alot of language and framework tutorials!

For the key actions that need to be applied to lists there are the classic CRUD ones, but also I wanted to add the notion of having a user "claim" an item. This is important for birthday and christmas lists so that who gift givers don't get the same gift. This was the first action and attributes for these items which depart from bog standard CRUD operations on data.

Prompt for small features

The ideal time to introduce an LLM tool to develop features is after you have the core data structures and how to manipulate at least somewhat complete. The data structures and the actions you want to take on them may evolve overtime, but it's difficult to describe both a desired feature and a proper data model in a single prompt so that's why I like to do it in this order.

Then in my experience it is best not to try to prompt to jump straight to the finished product you have in mind. Try to break up the jump to your vision of the web app into smaller chunks. This is of course no surprise to people who have been developing software for a while and is a best practice not because it is written in a book somewhere but because it makes each change easier to reason about for both humans and for machines.

But just because you want to break up the changes into discrete steps doesn't mean they have to be tiny in terms of line count or even in terms of impact. Just conceptually smallish! For my case one of the first additional features I wanted to develop after the data foundation had been laid was to add users and the pheonix views to be able to create lists and add items.

On the one hand this is a big change from what I already had, I didn't set up Phoenix yet, I didn't have users abstraction, and I didn't have any of the front end templates setup. But the quality of the current models is such that you can prompt in a way that leverages the frameworks you have chosen. Ash framework and Phoenix are known to work well together and Phoenix is very much ready to support the notion of users and users wanting to do CRUD actions on data. So even though there were quite of few lines that need to be written conceptually this was not a large jump and the model handled it well.

Test as you go

After you have a chunk of functionality up using classic testing practices is a good way to verify things are going well. I used a mix of unit testing and "integration" tests against a locally running db to make sure the functional behavior was correct. In addition Phoenix has excellent tooling for running the app locally so it's easy to very user workflows from the locally running app in your own browser.

I don't think there is too much difference in how to test for hand written versus augmented coding techniques. The main question is how much you rely on the model to write the tests. I find that it's best to really interrogate the model about the usefulness of the test as they tend to write alot of tests that don't really test any meaningful behavior of the system. Fewer but more impactful tests is better than 100 tests that don't really catch regressions or are annoying to update. Again this a classic insight from software engineering that is probably widely known.

Learning by doing?

One of the goals I had this with project was to teach myself more about the front end bits of pheonix. The classic approach to learning a new technology is to build something with it. This naturally takes you on a journey to discover how to use the thing. But with LLMs, I notice that the learning by doing is much less impactful than doing something by hand. I think this is a large trade-off. Of course I ended with a functional program much faster with LLM usage, but I don't feel deeply knowledgable about HTML HEEx yet. I know more than I did to start with but I feel not as much as if I had done it "the old fashioned way." So learning outcomes of building this project were not as good as other methods.

Setting up a hugo static site hosted with Porkbun

jsph — Wed, 01 Apr 2026 02:59:11 +0000

Content generation

This is a static site generated with hugo with the PaperMod theme. I wanted an easy to use static site generator. I considered Jekyll and believe it to be a good choice for static sites. There seemed to be slightly more themes I liked with hugo so I went with that. That's a pretty superficial choice but I also don't plan on hacking on the site generation itself so I was agnostic to the Go versus Ruby choice.

Domain hosting

This site uses porkbun for a domain host. I chose it not least because I do enjoy porkbuns. They also listed static site hosting as a service which suited this site well.

Porkbun link-in-bio versus static hosting

By the time I wanted to host this site, I either made the choice without remembering or it is a default setting to have new sites use the "link in bio" hosting plan (which is free). But I need to pay their small fee to host a static site. I then found porkbun's helpful FAQ, which helped me change out of link in bio mode to static hosting mode.

Github Integration

If you don't want to upload your files directly from your computer Porkbun offers GitHub connect to automatically publish changes to the site. But I had some confusion about how the generated site should sit in the directory structure. The integration let's you pick a repository and a branch on that repository to watch.

File structure Porkbun expects

I first chose main, but the integration didn't appear to work. The issue I think is the strucuture of the files for the static site that Porkbub accepts. By default hugo exports the generated static files to a directory public. The file hierarchy roughly looks like the following after you create a new project and render the files:

.
├── archetypes
│   └── default.md
├── assets
│   └── css
├── content
│   └── posts
├── data
├── hugo.toml
├── i18n
├── layouts
├── public
│   ├── 404.html
│   ├── assets
│   ├── categories
│   ├── index.html
│   ├── index.xml
│   ├── page
│   ├── posts
│   ├── sitemap.xml
│   └── tags
├── static
└── themes
    └── PaperMod

We can see that the public directory contains all the files and directories for the site.

Some other static file hosting servies let you point to a directory that contains the files for the static site, but it appears that Porkbun expects that these files be at the root of the github repo and branch you point it. Rather than overwrite main to just have the contents of public we can create another branch that contains only what we need.

Setting up a deploy branch

I had Claude generate a github action to create the generated files in a different branch deploy. Something like .github/workflows/deploy.yml

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: true

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: 'latest'

      - name: Build
        run: hugo --minify

      - name: Deploy to deploy branch
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public
          publish_branch: deploy
          force_orphan: true

Then I set the branch to watch to deploy in the porkbun UI and that did the trick. There were a few error messages but it seemed to not matter because now you are reading this and so it worked.