Skald

Skald is a multi-tenant backend for orchestrating AI-assisted video production. A user supplies a channel configuration and a video idea; the system coordinates the work needed to produce scripts, titles, chapters, voiceover, visual prompts, generated media, an assembled video, and a thumbnail.

The interesting problem is not making a single model call. It is turning many slow, failure-prone, provider-specific operations into a system with durable state, retries, workspace isolation, secure credentials, and large artifacts.

A Rust workspace with explicit boundaries

Skald is a Rust monorepo divided into focused crates:

• An Axum API handles authentication, workspaces, channels, projects, configuration, and job submission.
• Shared models define the PostgreSQL-backed domain.
• A pipeline crate contains the generation stages and provider integration.
• A worker crate executes durable background jobs.
• Storage and secrets crates isolate external infrastructure behind traits.

This separation keeps the video pipeline independent from HTTP concerns and prevents application code from becoming coupled to a particular object store or secrets service.

PostgreSQL as the durable work queue

Pipeline work is broken into discrete blocks such as script, titles, chaptering, voice, image prompts, media generation, editing, and thumbnails.

Jobs live in PostgreSQL alongside their state rather than being handed to a separate broker. Workers claim due rows using FOR UPDATE SKIP LOCKED, allowing several processes to drain the queue safely without selecting the same job. A claimed job receives a renewable lease. If a worker disappears, a reaper returns the expired job to the queue up to its retry limit, with exponential backoff between attempts.

The result is deliberately understandable: the work awaiting execution, its attempts, errors, timing, and final result are all represented in durable rows that can be inspected with ordinary database tools.

Workspaces, providers, and keys

Every channel, project, API-key reference, and provider choice belongs to a workspace. Membership roles and signed sessions control access, while database queries and storage prefixes maintain the same boundary below the API.

Skald uses a bring-your-own-key model. The database holds references to provider credentials, never the key material itself. A trait-based secrets layer supports environment-backed development and HashiCorp Vault. Keys are resolved only where pipeline work needs them.

Provider models and their capabilities are data rather than hard-coded assumptions. A workspace can select which provider and model handles each block and variant, while relational constraints prevent incompatible combinations.

Artifacts belong outside the database

Scripts, audio, images, clips, assembled video, and thumbnails are stored through a common asynchronous storage interface. Local storage is useful during development; the S3 implementation also works with compatible services such as MinIO.

The pipeline uses ffmpeg and image processing where deterministic local work is preferable to another remote service. Project state ties each completed block to its resulting artifacts so later stages can locate their inputs.

The system around the pipeline

The API includes registration, email verification, password reset, workspace membership, channel configuration, projects, jobs, and provider-key management. Configuration comes from TOML with environment overrides. SQLx verifies queries against the schema, migrations make changes explicit, and structured tracing provides a consistent view across the API and workers.

Skald is an exercise in making a large chain of creative operations behave like an engineering system: bounded components, durable work, inspectable state, and recovery designed in rather than added later.

Want to try it?

It is not yet available for public consumption, but watch this space.