Hosting Static Sites: Astro, Hugo, and 11ty on TrueCore

You have just finished a redesign of a marketing page in Hugo and the build folder sits on your laptop. The next step is to get those static files onto your live domain without touching a database, without breaking your existing SSL, and without waiting for an external CDN to propagate.

TrueCore makes that path straightforward. Every plan serves your files with nginx 1.28 and gives you a fully functional SSH shell where rsync, git, and the site CLI live side-by-side. There's no PHP on the entry-level Flameling tier — it's a static-only plan — and PHP-FPM only appears on Ember and up, but a static site never needs it anyway. Below we walk through two common workflows - building locally then syncing, and building directly on the server - and show how to set cache headers and redirects in the same place you manage your DNS.

Static sites line up with our infrastructure

The moment you choose a static-site generator (SSG) you avoid the need for a database backend. That lines up with every TrueCore plan, from the £10 Flameling tier up to the £80 Inferno tier: each includes per-site nginx pods, automatic Let's Encrypt certificates, and kernel-enforced resource limits. The only thing you lose is a MySQL or SQLite instance, which you never needed in the first place.

Because nginx serves files directly from the web root, the performance impact is minimal. The flame-guardian nftables firewall protects the node, and the flame-bubble container isolation keeps each site sandboxed. There is no hidden proxy layer that would strip away cache-control headers you set in your build output.

Build locally, then push with rsync

Most developers prefer to keep the build step on a workstation that already has the SSG installed. After running hugo or astro build you end up with a directory of HTML, CSS, JS, and image assets. Syncing those files to TrueCore is a single command.

# Replace example.com with your actual domain
rsync -avz --delete public/ username@example.com:/home/username/web/

• -a preserves permissions, timestamps, and symlinks.
• -v gives you a progress view.
• -z compresses the transfer - useful on slower uplinks.
• --delete removes files that disappeared from the local build, keeping the live folder clean.

The command works because the SSH key you added in the portal (see our SSH Access guide) authenticates you automatically. Once the files land in /home/username/web/ the nginx pod picks them up instantly; there is no extra reload step required.

Setting cache headers without a CDN

If your SSG does not output cache-control meta tags, you can add a small nginx snippet via the site CLI:

site config add <<EOF
location / {
    try_files $uri $uri/ =404;
    add_header Cache-Control "public, max-age=31536000, immutable" always;
}
EOF

The always flag makes sure the header appears even on error pages, which is handy for assets that never change. Note that nginx does not read Apache .htaccess files, so all header and caching rules live in your site's nginx config via the site CLI. For files you want to keep fresh, such as index.html, add a more specific location block that overrides the broad rule:

site config add <<EOF
location = /index.html {
    add_header Cache-Control "no-cache, must-revalidate" always;
}
EOF

Build on the server via SSH

If you prefer to keep your source repository on the server, the same tools are at hand. After adding your SSH key you can clone a git repo directly into the web root and run the build command on the node. The site CLI also offers a shortcut to install common build tools.

ssh username@example.com
cd /home/username/web
git clone https://github.com/yourname/your-hugo-site.git .
hugo --minify
site ssl renew   # makes sure the certificate matches the freshly built site

Because the server runs Alpine Linux on ember (in Nuremberg) you get a musl libc and a lightweight environment. The flame-bubble isolation means the build process cannot escape its container, protecting other customers on the same node.

Building on the server can reduce the need for a large local dev machine, and it guarantees that the generated files match the exact runtime environment you will serve. The trade-off is a slightly longer build time, as the CPU on the shared node is limited by the plan's resource caps. For most Hugo, Astro, or 11ty sites the difference is a few seconds, well within the 30-minute backup window of our Inferno tier.

Redirects and rewrites without a database

Static sites still need redirects - for example, moving /old-page/ to /new-page/. With nginx you can add a simple location block using the site CLI:

site config add <<EOF
location = /old-page/ {
    return 301 https://$host/new-page/;
}
EOF

If you have many redirects, keep them in a plain text file and load it with an include directive:

# Create redirects.conf in the web root
cat > redirects.conf <<'EOT'
rewrite ^/blog/(.*)$ /news/$1 permanent;
rewrite ^/store/(.*)$ /shop/$1 permanent;
EOT

site config add <<EOF
include /home/username/web/redirects.conf;
EOF

Because the configuration lives alongside your site files, a single git pull or rsync can bring both content and redirect rules into sync. No separate database table, no WordPress plugin, just plain nginx directives that reload automatically the next request.

TL;DR checklist

• Add your SSH key in the portal (refer to the SSH Access post).
• Choose a build workflow: local rsync or on-server git + build.
• Deploy with rsync -avz --delete or via site CLI.
• Set long-term cache headers with add_header Cache-Control.
• Add permanent redirects using site config add and optional include.
• Verify SSL with site ssl renew - the cert updates automatically.

Whether you are a freelancer pushing a personal portfolio built with 11ty, an agency rolling out a Hugo-driven blog, or a small shop using Astro for a product showcase, TrueCore gives you the low-overhead environment you need. No database, no extra CDN config, just static files served by a modern nginx stack, protected by our custom firewall and monitoring tools. Deploy, tweak, and watch the site load in a flash.