GitHub Pages and a custom subdomain.

What we wanted to achieve

We wanted a vibrant landing page available at swe.tickerbell.biz. The source code would remain public on GitHub, GitHub Pages would host the frontend, and the existing tickerbell.biz domain would continue to work normally.

The simple architecture

The setup used four connected pieces:

1. HTML, CSS, and JavaScript created the page.
2. The swe-tickerbell repository stored the production frontend.
3. GitHub Pages served the files publicly.
4. A DNS CNAME record connected swe.tickerbell.biz to GitHub Pages.

Separating the learning repository from the production repository made the structure clearer: document the process in Become-SWE and publish the actual frontend from swe-tickerbell.

The implementation steps

1. Create the production repository

We created a public repository named swe-tickerbell and placed the landing page at the repository root as index.html. GitHub Pages looks for this entry file when it serves a simple static site.

2. Turn on GitHub Pages

In the repository settings, GitHub Pages was configured to deploy from the main branch. This changed the repository from a storage location into a hosting source.

3. Add the custom domain

The custom domain field was set to:

This also requires a repository file named CNAME containing the same hostname.

4. Configure DNS

At the domain provider, we created a CNAME record for the host swe and pointed it to the GitHub Pages hostname. DNS changes can take time to propagate, so an immediate failure does not always mean the configuration is wrong.

5. Verify the full path

We checked the repository, Pages configuration, CNAME file, DNS record, HTTPS status, and finally the public URL in a browser.

What made the work difficult

The hardest part was understanding that several systems had to agree at the same time. A correct HTML file does not guarantee a public website. A correct GitHub Pages setup does not guarantee that the custom subdomain resolves. A correct DNS record can still appear broken while caches update.

The repeated waiting and checking felt uncertain because the browser only showed the final result, not which layer was responsible. The solution was to test one layer at a time rather than changing everything together.

What I learned

• A static website can be hosted without a traditional server.
• GitHub is both a collaboration system and a deployment source.
• A subdomain is created through DNS; it does not require buying another domain.
• The CNAME setting must be consistent in GitHub and at the domain provider.
• Deployment troubleshooting is easier when code, hosting, DNS, and browser cache are tested separately.
• Documentation turns a frustrating one-time task into a reusable process.

Reusable checklist

1. Confirm that index.html works locally.
2. Push the file to the publishing branch.
3. Enable GitHub Pages.
4. Add the custom domain in Pages settings.
5. Confirm the repository CNAME file.
6. Create the DNS CNAME record.
7. Allow time for propagation.
8. Test the HTTPS address in a private browser window.