DEV Community

w4ffl35
w4ffl35

Posted on

How I built Capsize Online as a static Django site

I built Capsize Online to collect my public software, games and release notes in one place. I wanted Django for editing, but I did not need a live application server for pages that only change when I publish them. The site compiles the Django content into static files for production.

The site went live during the week with the shared Capsize shader identity and a tag-driven deploy path. The authoring database stays local. The production server receives the compiled output, not a running Django application. That keeps the public surface simple while leaving the content workflow pleasant to edit.

The output can live on any plain web server. Each tagged build also leaves a clear release and rollback point.

The site links AIRunner, SpikeForge, the Capsize Audio Visualizer, Capsize Games, WXRQ and my personal site. Its devlog can connect a project update directly to the repositories and releases behind it.

The live portal is capsize.online. The four-week release story is in Four weeks of building in public, with the technical project notes collected on DEV. The report links each public repository directly.

A small Django site pattern

Keep the content model small. A title, a slug, a summary, a body, a date and a publication status are enough for a useful devlog. Render the body to a static route during the build. Put the public images in the static tree and let the compiler carry them with the page.

This pattern works well for a project portal because the authoring experience and the deployment target have different needs. Django is a good editor. Static HTML is a good thing to serve.

The first version of the site was a list of links. The current version is closer to a small index of finished things: a project has a page, a release has a place to land, and a reader can move from a chart to the thing that produced it.

That is a modest job for a website, but it is a useful one. The portal does not need to explain every implementation detail. It needs to make the next click obvious and keep the project names, release pages and public work in one place.

Top comments (0)