Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/aurora-borealis/llms.txt

Use this file to discover all available pages before exploring further.

Aurora Borealis compiles to a fully static bundle — HTML files, a JavaScript bundle, a CSS file, and component modules — with no server-side rendering and no backend. This makes it deployable to any static hosting service with zero server configuration. Hash-based routing further simplifies things: the host never needs to inspect or rewrite URLs.
The repository already contains a pre-built production bundle. No build step is required for vanilla deployment. Simply upload the repository files to your static host and the site is live. You only need to run vite build if you have modified the source project and need to regenerate the bundle.

​
What gets deployed

The repository root contains everything the site needs — there is no separate dist/ output directory to generate before deploying: 
aurora-borealis/
├── index.html                   # Root entry point (/)
├── pages/
│   ├── About.html
│   ├── CaseStudies.html
│   ├── Contact.html
│   ├── Home.html
│   ├── Projects.html
│   ├── Skills.html
│   └── Writing.html
├── assets/
│   ├── main.js                  # React app bundle
│   ├── main.css                 # Compiled Tailwind styles
│   ├── jsx-runtime.js
│   └── proxy.js                 # Framer Motion proxy
├── components/
│   ├── AuroraBackground.js
│   ├── ConstellationNav.js
│   └── StarField.js
└── useScreenInit.js
No Node.js server, no API routes, no SSR. Upload the repository contents to your host and the site is live.

​
Hash routing on static hosts

Aurora Borealis uses hash-based routing (/#/about, /#/projects, etc.) rather than history-mode routing. This means the server always receives a request for the base HTML file — the hash portion (#/about) is processed entirely in the browser by React Router. No 404 redirect rules or _redirects files are required on any host.
With history-mode routing (e.g. /about as a real URL), every host needs to be configured to serve index.html for unknown paths, otherwise a direct visit to /about returns a 404. Hash routing sidesteps this entirely: /about is never sent to the server. This is why the per-page HTML files in pages/ each contain a small inline script that immediately redirects to the hash equivalent — the server only ever serves the HTML file, and the browser navigates from there.

​
Static hosting options

GitHub Pages serves static files directly from a repository branch or a docs/ folder. Aurora Borealis already ships a .nojekyll file at the project root, which prevents GitHub’s Jekyll processor from interfering with the Vite output.Deploying the pre-built bundleBecause the repository already contains a pre-built static bundle, you can deploy directly from the repo without a build step. Push the repository to GitHub and configure Pages to serve from the main branch root (or copy the files to the gh-pages branch).Automatic deployment with GitHub Actions
# .github/workflows/deploy.yml
name: Deploy to GitHub Pages
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: .
If you have modified the source project and need to rebuild, add npm ci and vite build steps before the deploy step, and set publish_dir: ./dist to point at the build output.Hash routing works out of the box — no 404.html redirect hack is needed because the per-page HTML files in pages/ handle direct visits themselves.

​
Custom domain

All four hosts above support custom domains through their dashboard or DNS settings. The general process:
  1. Add your domain in the hosting provider’s dashboard.
  2. Create a CNAME DNS record pointing your domain (e.g. portfolio.yourdomain.com) to the host-provided URL (e.g. youruser.github.io or your-site.netlify.app).
  3. For apex domains (e.g. yourdomain.com without a subdomain), use an ALIAS or ANAME record, or follow your host’s specific apex domain instructions.
No special server configuration is required. Because Aurora Borealis is a static site with hash routing, the custom domain behaves identically to the default host URL.

​
Environment variables

The base portfolio requires no environment variables. All content, colors, and animation parameters are hardcoded in the source files. If you extend the project — for example, by adding a working contact form that posts to a backend API — store the endpoint URL as an environment variable so it is not hardcoded in source: 
# .env.local (never commit this file)
VITE_FORM_ENDPOINT=https://api.yourdomain.com/contact
Vite exposes any variable prefixed with VITE_ to the client bundle via import.meta.env: 
// In your contact form component source
const response = await fetch(import.meta.env.VITE_FORM_ENDPOINT, {
  method: "POST",
  body: JSON.stringify(formData),
});
Set the same variable in your hosting provider’s environment variable dashboard (not in a committed file) so the production build picks it up at build time.
Variables injected via import.meta.env are embedded into the compiled assets/main.js at build time — they are not secret. Never store API keys, tokens, or passwords in VITE_-prefixed variables. Use those only for non-sensitive configuration such as public endpoint URLs.

​
Build commands reference

These commands apply only if you have the original Vite source project and have modified source files. The deployed repository is a pre-built static bundle — no build step is required for vanilla deployment. 
# Start the Vite dev server with HMR
vite
# or
npx vite

Build docs developers (and LLMs) love

Get started for freeTalk to us