melltron.build — loghttps://melltron.build/2026-11-02T00:00:00ZEthan MellonBootstrapping melltron.buildhttps://melltron.build/log/bootstrapping-melltron-build/2026-11-02T00:00:00ZWhy this site is a static Worker, why apps live on subdomains, and why it's kept apart from company infrastructure.<p>This site has two jobs: a build log (this) and a lab — a registry of tools and experiments that each run on their own <code>*.melltron.build</code> subdomain.</p>
<h2>Decisions</h2>
<p><strong>Static assets behind a thin Worker.</strong> Content is Markdown, rendered to HTML by a small Python script and committed. The Worker only enforces the canonical host, security headers, and cache policy. No framework, no build step at the edge — the deployed artifact is exactly what’s in the repo.</p>
<p><strong>One Worker per lab app.</strong> Experiments break. Isolating each on its own Worker and subdomain means a bad deploy in the lab can’t take the root site down, and each app can be retired without touching anything else. The root only keeps a registry pointing at them.</p>
<p><strong>Personal accounts, not company ones.</strong> Repo, DNS, and Cloudflare account are personal. Mixing a personal domain into company infrastructure blurs ownership — it surfaces in IP assignment, in due diligence, and on the day anyone leaves. Separating it costs nothing now.</p>
<h2>Status</h2>
<table>
<thead>
<tr>
<th>Part</th>
<th>State</th>
</tr>
</thead>
<tbody>
<tr>
<td>Root site</td>
<td>live</td>
</tr>
<tr>
<td>Feed / sitemap</td>
<td>live</td>
</tr>
<tr>
<td>Lab apps</td>
<td>none yet</td>
</tr>
</tbody>
</table>