Skip to main content

aptlantis Overview

aptlantis is the schema-driven mirror and archive website behind aptlantis.net — cataloging Linux distributions, package snapshots, torrents, ISO images, TempleOS/Terry Davis videos, and datasets, with JSON Schemas defining every content type and LLM instruction snippets embedded directly in the site manifest to drive automated metadata generation.

:::note Framework evidence is mixed between Astro and React/Vite The analyzer's evidence (package.json, vite.config.js) points to a React + Vite frontend, but the production docker-compose.yml found in this session builds an Astro Node.js server for SSR/hybrid rendering. This looks like evidence of an in-progress or partial framework migration rather than a documentation error — worth confirming directly against current source before treating either description as final. :::

Who it's for

Both public visitors retrieving ISOs/torrents/datasets, and the operator maintaining mirror status and archive metadata — this is explicitly described as "operator-centric archive and mirror website: canonical archive front-end, metadata generator, and operator dashboard."

The core concept

Everything content-related is schema-first: AptlantsSchema.toml / AptlantisSchema.json define the site's structure, and public/schemas/*.json provides individual JSON Schemas per content type — distro.schema.json, torrent.schema.json, dataset.schema.json, iso-image.schema.json, templeos-video.schema.json, snapshot.schema.json, mirror.schema.json.

AptlantsSchema.toml (site manifest, includes llm.instructions)


public/schemas/*.json ──▶ public JSON catalogs (distros.json, torrents.json, artifacts.json)


React/Vite (or Astro) frontend ──▶ built static site (dist/)


Caddy (Docker) reverse proxy ──▶ https://aptlantis.net

public/data/mirror-status.json tracks per-distro sync state and last-updated timestamps — a live operational dashboard baked into the static site's own data, not a separate monitoring tool.

Why this shape

The llm.instructions embedded directly in the site manifest are operationally significant, not just documentation — they drive automated metadata generation and reconstruction for archive entries, meaning an LLM is a working part of the content pipeline here, not just a development aid. Given the scale (distros, ISOs, torrents, video transcripts, snapshots), hand-authoring metadata for every archive entry wouldn't be sustainable for a single operator.