FM PRO TECH 5 — Aenaos Records (Falk Merten)
Leipzig-based Aenaos Records develops a static-first label infrastructure with its Label Site Generator. A system that turns Bandcamp catalogues into fully structured websites without ongoing maintenance.
Version 5.0 rebuilds the workflow; onboarding reduced to a single command, with automated scraping, configuration, and a redesigned frontend.
The system uses Bandcamp as its base, expanding into streaming links, physical formats, and metadata through API enrichment, removing duplicate catalogue management.
Originally an internal tool, it has evolved into an open-source framework for labels and artists moving away from CMS-heavy setups toward a faster, static model.
The result is a controlled pipeline: scrape, enrich, render, then ship.
Alongside the release, Aenaos launched a rebuilt label site and public template previews, showing how the same data structure can power different visual outputs without touching the underlying system.
FM PRO TECH 5 breaks down how the generator handles data consistency, API normalization, static performance, and scalable design systems. Without adding backend complexity.
Q1. Bandcamp as source of truth. How do you manage data consistency, caching, and update cycles from a live catalogue?
Bandcamp is where labels already do the careful work. Artist names, release titles, track lists, dates, artwork – that information is usually maintained with more attention than people expect. So instead of rebuilding the same catalogue somewhere else and ending up with two versions of the truth, we just treat Bandcamp as the starting point.
The generator scrapes the full catalogue into a local JSON cache. For Aenaos Records that’s around 200 releases across 18 artists – roughly 80,000 lines of JSON. Once that cache exists, normal site generation doesn’t touch Bandcamp at all. It reads local data and renders.
Updates are explicit. You run –scrape when something changed. That sounds old-fashioned, but for a label catalogue it makes sense. Releases don’t change every five minutes. When we re-scrape a single artist, the system keeps all the enriched data – streaming links, UPCs, Discogs metadata – and only refreshes what comes directly from Bandcamp.
We just finished a major refactoring for v5.0 that simplifies this further. The entire onboarding is now one env var and one command. The generator detects your account type, asks a few questions, scrapes, generates a config file, and builds the site. No manual setup of multiple config files anymore.
The rhythm is simple: scrape when something changes, enrich when you want streaming links, deploy when it looks right. No background sync, no cron jobs. Predictable.
Q2. Pure HTML output. Why skip CMS/backends, and how does that impact performance and scale?
Plain HTML, CSS, a bit of vanilla JavaScript. No framework, no client-side rendering, no database. The site goes to S3 with CloudFront in front.
The reason is practical. A label website is read-heavy and changes rarely. No login, no shopping cart, no dynamic logic that needs a server. People arrive, listen, read, click through to Bandcamp or a streaming platform, maybe sign up to a newsletter. For that, static files on a CDN are hard to beat. Fast, cheap, stable, almost nothing to maintain.
Scale isn’t the hard part. Even a much larger catalogue would generate quickly. The bottleneck is external enrichment – talking to APIs, matching releases. A normal build from cache takes about five to eight seconds. Image optimization takes longer the first time when Sharp creates WebP and mobile variants, but after that it skips what’s done.
The trade-off is that anything interactive happens in the browser or through an external service. Newsletter signup posts directly to the provider’s API. News articles come from a headless Ghost instance – the generator pulls them at build time via the Content API, so editors can write in a proper CMS without the website needing a server at runtime. If Ghost is down, it falls back to local Markdown files. But honestly, for this kind of website the dynamic surface area is very small and manageable.
Q3. Pulling from Spotify, Apple Music, and Discogs. How do you standardize data across APIs and formats?
The Bandcamp scrape gives us the core catalogue. Enrichment fills in what Bandcamp doesn’t provide: streaming links, UPCs, physical formats, label metadata.
Most of that starts with Soundcharts, because it returns links across several platforms in one call – Spotify, Apple Music, Deezer, Tidal, Amazon Music, YouTube Music. When Soundcharts doesn’t find a match, the system falls back to direct searches: Spotify for links and metadata, iTunes Search API for Apple Music, Deezer’s public API, Tidal.
Discogs sits apart because it answers a different question. It’s about physical releases – vinyl, CD, cassette editions, marketplace listings, sell URLs. It also provides label attribution that sometimes differs from Spotify, which is useful when a release went through different distribution channels.
The important part: the final data structure is always the same regardless of source. Each album ends up with predictable fields – streamingLinks, physicalFormats, labelName, upc. Then the merger combines that with local content, and local content always wins.
That last point matters because music metadata is messy. The same record appears under slightly different titles or dates depending on the platform. Automation helps, but it shouldn’t overrule what you know is correct. If we’ve set something locally, the system respects that.
In v5.0 we also tightened the UPC priority chain. Bandcamp CSV exports matched by album ID are now preferred over Spotify UPCs, because the structural match is more reliable than title-based matching across platforms. Spotify UPC is still available but only in force mode with confidence gating.
Q4. Node.js + Nunjucks. How flexible is the templating for custom layouts, branding, and extensions?
Nunjucks works well because it gives enough structure without turning the site into an application. Inheritance, blocks, macros, filters, conditionals – everything you need for a proper layout, but with a simple mental model.
The base template defines the shared shell. Individual page templates extend it and replace what they need. An album page overrides the hero section, renders streaming links and track lists, adds structured data. An artist page shows bio, discography, events, gallery.
For branding, the idea is that a label shouldn’t have to touch the data pipeline to change the visual identity. The Aenaos Records theme is its own thing – dark, glassy, atmospheric, around 950 lines of custom CSS. But another label could use the same generator with a completely different look.
We have three built-in themes now – standard (light), dark, and Bandcamp (which auto-extracts colors from your Bandcamp page). Plus a blueprint for designers who want to build their own. Custom CSS in content/global/style.css overrides everything.
We’re also building per-artist templates where each band gets its own visual world. Not a color swap on a shared skeleton, but genuinely different layouts. One artist might get a theatre-programme structure. Another a torn-zine collage. Another a film-dossier layout with serif credits. The generator handles the same data slots underneath – hero, release, track list, streaming links, press, newsletter – but the presentation is individual. Visitors should recognize the artist, not the website builder.
Q5. GPL-3.0 open-source. How do you see it evolving, and what integrations are next?
The open-source version should stay focused. Scrape, enrich, merge, render. That core already covers most of what an independent label needs: artist pages, release pages, streaming links, physical buy links, news, events, newsletter, structured data, sitemaps, RSS.
We just shipped v5.0 which was a significant refactoring of the onboarding experience. The old setup required multiple config files and several env vars. Now it’s one URL, one command, and the generator figures out the rest – account type detection, interactive prompts, automatic config generation. That was important because the previous version assumed too much technical comfort.
The next phase is rolling it out for artists on our roster who need standalone websites. That’s pushing two things: an artist-site mode alongside the label mode, and ready-made themes so people don’t start with a blank file.
Beyond standard themes, we’re developing differentiated artist templates. We have eight prototypes in various stages, no two share a visible skeleton. The same enriched data feeds into completely different visual worlds. A label can generate artist sites where each band looks like they have a bespoke website, not a platform page.
Smaller things on the backlog: merchandise display from Bandcamp, metadata quality flags so you can see what’s complete and what needs attention, and a Spotify-first onboarding path for labels that don’t use Bandcamp.
Longer term, a hosted version makes sense. Not every label wants to run a generator locally. But the open-source version stays the engine underneath.
We’re also open to store integrations if there’s demand – connecting with platforms like Bandcamp merch, print-on-demand services, or independent record shops. Right now the generator links out to existing stores, but tighter integration is something we’d explore if labels need it.
The area I’m most interested in improving is matching. Music metadata is rarely clean. One album can have different titles, dates, or label credits depending on where you look. We handle that with heuristics and manual overrides right now. I’d like to make it smarter without making the experience heavier. The best version of this tool should feel calm – it does a lot in the background, but it doesn’t ask you to become a metadata engineer.
If anyone running a label has ideas or needs that aren’t covered, we’re open to hearing them. The project lives on GitHub, and feature requests are welcome.
Aenaos Records compresses label infrastructure into a static system that removes friction where it usually compounds.
©fm