Run a BBC TAMS store on your own infrastructure
TAMOSS is an open-source, Kubernetes-native implementation of the BBC TAMS API. One product, one deployment model, with the flexibility to run it based on your unique scenario.
A single laptop, a server, a full hybrid cloud setup, or at an enterprise scale across regions. Complete flexibility, all without vendor lock-in.
Built for how live and file-based media actually work
Time-Addressable Media Store (TAMS) is reshaping how broadcasters and media teams work with content. Rather than copying whole files between systems, media lives as immutable, timestamped segments addressed by time. Editors can start cutting a feed while it is still being recorded, live and file-based workflows share a single store, and moving content between tools stops meaning moving petabytes. Developed by BBC R&D, TAMS is one of broadcast's most closely watched standards, with backing from AWS, Reuters and others.
TAMOSS brings that model to your own infrastructure: an open-source, Kubernetes-native TAMS store, with no proprietary extensions and no vendor lock-in. What you install is a Kubernetes operator and the store it manages. You describe the store you want as a declarative custom resource, and the operator builds it, holds it there, and runs its lifecycle. The same product runs on a laptop, a single server, or a multi-region cluster, so your team owns the store end to end and runs it wherever your content needs to live.
TAMOSS is the store, not the toolchain. It does not replace your editor, your transcoder, your playout system or your media asset manager. It gives all of them one time-addressable place to read from and write to over an open API, which means you can change any of those tools without moving the content.
Media platforms shouldn't decide where your content lives.
Content stores bundle storage with their tools, their cloud, and their pricing model. It works until you hit those use cases where it doesn't.
Your platform only runs where your vendor lets it.
The storage and tools with Avid, Adobe, Frame.io all come bundled together. The cloud and terms are theirs.
Outside broadcast needs infrastructure that travels.
Cloud-only stores impact productivity when production is on the road, the connection is patchy, or the venue dictates where the kit lives.
Switching cloud means migrating petabytes.
Proprietary stores make exits expensive. The longer you stay, the more complex it gets when the business needs to move.
The same product, sized to your workload.
Kubernetes has a reputation for being heavy, but TAMOSS is the counter-example. A single declarative deployment that scales from a laptop to a data centre, without the need for re-architecting.
Deployment 1
Local
A single node. Runs on your laptop with Kind in just two commands, and you have the full stack.
Best for: remote editing, development, demos
Hardware: Your laptop
Deployment 2
Single server
One dedicated machine. Choose between on-prem, a VM or in your chosen cloud.
Best for: single productions, OB trucks, small facilities
Hardware: one server, on-prem, cloud or virtual
Deployment 3
Multi-server cluster
Replicas, redundancy, and scale. The same TAMOSS, configured for large production load.
Best for: facility-wide and multi-site operations
Hardware: any conformant Kubernetes
Built for media, built by platform engineers.
Tool choice flexibility
Vendor-neutral store
Any application that speaks the TAMS API can read from it and write to it. Whether that is your editor, your transcoder, your playout system, or your archive.
Camera-to-cloud ingest
Ingest content from cameras and devices in the field, without committing to one vendor's ecosystem.
One pattern, every workflow
News, sport, and post-production workflows can run on the same underlying infrastructure.
A cost shape you control
Pay for the storage and compute you actually use, not for a per-seat licence on the store itself.
Production-grade deployment
Driven by a Kubernetes operator
Declare the store you want as a custom resource and the operator reconciles it. It corrects drift when a resource is changed, reports health through status conditions and Events, and guards destructive deletes behind an explicit confirmation.
BBC TAMS v8.1, no extensions
No proprietary API surface. Only Kubernetes-native conventions (/healthz, /readyz) plus runtime concerns the spec leaves open.
Modern stack, no surprises
FastAPI backend. PostgreSQL for metadata. RustFS for S3-compatible object storage. Helm-deployable on EKS, GKE, AKS, or any conformant Kubernetes.
OpenTelemetry-ready
Conditional instrumentation. Bring your own collector, Prometheus, and Grafana, with no bundled observability stack to fight.
Durable async lifecycle
Workers for flow deletion, webhook delivery, and object cleanup. PostgreSQL-backed claim semantics with exponential-backoff retry. The operations work has already been done.
Ways teams put TAMOSS to work.
Outside broadcast
The truck rolls up. TAMOSS is already running on the kit on board. The production records, edits, and reviews against a local TAMS store, no dependency on a cloud connection that may or may not be there. When the truck rolls back, the store syncs to the facility archive. The infrastructure travels with the production. The workflow doesn't change.
Hybrid post-production
Editors on Adobe Premiere, DaVinci Resolve, Avid Media Composer, and Final Cut Pro all reading from the same TAMS store. Switch tools without migrating media. Add a transcoder, an AI service, a review platform, anything that speaks TAMS, and it joins the same pool of content. The store is the constant; the tools are the variables.
News at scale
A 24/7 newsroom takes feeds from everywhere at once, live crews, agency wires, file drops from stringers. Every one lands in the same TAMS store the moment it arrives, addressable by time before the recording has even finished. Journalists cut running stories against those segments while the feed is still live, and playout pulls from the same store, with nothing copied between systems to make a deadline. The long-tail archive sits behind the same API, so this minute's incoming feed and last year's package are reached the same way. One store, one API, on infrastructure the broadcaster controls.
What's inside the stack.
Delve into the TAMOSS tech. Browse the runtime topology, the request flow, and the code structure beneath. For the reasoning behind the design, read why TAMS is a Kubernetes-shaped problem.
Kubernetes deployment topology
Application architecture & request flow
Code structure & data access layers
Watch the full deployment, end to end.
A TAMOSS product overview and a live deployment from an empty cluster. This demo contains a walkthrough of the API, the deployment mechanism, an ingest, and a look at how third-party tools connect to our TAMOSS deployment. The technical demo is for engineers who want to see the product in action before committing time to a pilot or implementation.
Ready to get started?
Clone the open source version or learn more about our professional services.
Open source, pilot, or partnership.
As TAMOSS is open-source, there are multiple deployment options depending on your needs. Start with the open-source product, or engage LiveWyer for additional deployment support.
Self-serve
Free · Apache 2.0 · Community support
Clone the repository. Deploy with Helm by following the step-by-step guide on GitHub. This is a completely free TAMOSS deployment, with free support available via the TAMOSS community Slack.
Best for: engineering teams evaluating TAMOSS, smaller deployments, and contributors.
LiveWyer Pilot
Fixed price · Fixed scope · Real workloads
We deploy, validate, and hand over a working TAMOSS using your chosen real-world workload on your chosen target. A fixed-price end-to-end Pilot with zero obligation for any further delivery efforts.
Best for: organisations validating TAMOSS against a specific workflow or production.
LiveWyer ProServe
Fixed price or T&M · Personalised scope
If your team needs support with implementation, LiveWyer have the delivery capability to help you succeed, integrating within your existing engineering team to supplement delivery and add immediate value.
Best for: organisations looking to build on the pilot implementation and need additional engineering support.
Delivery Partnership
Fixed price or T&M · Client delivery support
We collaborate with our partners and their customers to architect, build, validate solutions. If you have a customer who could benefit from an Open Source TAMS implementation, let's discuss how we can help.
Best for: Current and future partners with clients who need support with their TAMOSS implementations.
The hard part is everything after "it works".
Getting TAMOSS running is the easy part: clone the repo and you have a store on your laptop in two commands. The hard part is everything after 'it works', proving the store holds up with your workloads, on your infrastructure, with the tools your team already runs in their production workflows.
Our approach
We deploy a single-server TAMOSS on your chosen target, which can be one cloud, or one node. From there, we ingest a real workload that's representative of how you actually work. We then connect one or two of your existing tools over the TAMS API to fully validate the path end to end, from ingest to retrieval.
The crucial success criteria for our initial pilot is that you are in the position to fully operate TAMOSS. We exercise the operator's day two behaviour against your store. It corrects drift when a resource is changed, reports health through status conditions and Events, guards destructive deletes behind an explicit confirmation and runs the async lifecycle that keeps the store tidy. All parties leave the Pilot with evidence, documentation and operational knowledge to fully operate and maintain a TAMOSS store in your environment.
0
Vendor lock-in
v8.1
API compatibility
3 weeks
to validate
Prove TAMOSS on your own workflow in three weeks
Our fixed-price, fixed-scope pilot deploys TAMOSS on your infrastructure and validates it against a real workload with the tools your team already use. You leave with a working deployment, a runbook and the evidence to operate it - zero obligation to continue.
Two questions, answered with evidence
A working store is necessary but not sufficient. The pilot is scoped to settle both halves of the decision your stakeholders actually have to make.
It works on your workflow
A representative real workload, ingested on your chosen target, with one or two of your existing tools reading from and writing to the store over the TAMS API. Proof on your content and your toolchain, not a generic sample.
It's operable, not just running
The operator's day-2 work, demonstrated against your store: drift correction, readiness through status conditions and Events, an admission guard on destructive deletes, and the async lifecycle workers. Observability wired to a collector so you can see it.
Three weeks, six phases
The same structured path as our other pilots, with the operability work landing in validation and handover.
Drawn tight, on purpose
A fixed price needs a fixed boundary. Here's exactly what the pilot covers - and what sits beyond it, in the engagements the pilot is designed to set up.
In scope
Single-server TAMOSS on one chosen target - one cloud or one node
One representative real workflow, ingested end to end
One or two of your existing tools connected over the TAMS API
Operator day-2 demonstration: drift correction, status conditions & Events, destructive-delete guard, async workers
Observability hooked to a collector, or your Grafana where it's quick
Handover: the working deployment, an operations runbook, and a findings & evidence pack
Beyond the pilot
Multi-region or replicated production topology
Full toolchain integration beyond the one or two named tools
Production-scale data volumes or live content migration
Bring-your-own backends at scale (managed Postgres, S3 estate, OIDC)
These become the ProServe or managed-service engagement - see below
The pilot questions, answered head-on
Cary Haine, Head of Media Infrastructure
TAMOSS is open source, we could deploy it ourselves. Why pay for a pilot?
LiveWyer
You absolutely can - the self-serve route is free and supported
What you're buying is a fast route to confidence on your own workflow and your own infrastructure, plus the day-2 operability work proven up front rather than discovered later. You keep the deployment and the runbook either way; the pilot just gets you there in three weeks with evidence in hand.
Beryl Judingham, Platform Lead
You say 'operate', but a pilot is time-boxed. What does operating actually mean inside a fixed engagement?
LiveWyer
We demonstrate operability; we don't take on ongoing operations
Inside the pilot we prove the operator's day-2 behaviour against your store and document it in a runbook. Ongoing operation - SLAs, on-call, managed running - is a separate engagement the pilot is designed to set up, so the fixed scope stays fixed.
Sukayo Baka, Director of Technology
If the pilot goes well, what happens next?
LiveWyer
You choose the depth of the next step
Build on the pilot with ProServe - fixed-price or T&M - to take it to a production-shaped, multi-server deployment, or move to a managed model where we operate it with you. There's no obligation to continue: the pilot stands on its own.
Cary Haine, Head of Media Infrastructure
Are we locked into the one cloud we pick for the pilot?
LiveWyer
No - that's rather the point of TAMOSS
The pilot targets one cloud or node to keep scope tight, but the same operator-driven product runs on EKS, GKE, AKS or your own hardware. What you validate on the pilot target is what you run anywhere else, with backends and auth pluggable via the same declarative interface.
The team that builds TAMOSS is the team that supports it.
TAMOSS is not a third-party project we resell. We wrote the operator, we maintain the repository in the open, and the engineers who would run your pilot are the ones who built what you are deploying.
We maintain the project
LiveWyer authors and maintains TAMOSS in the open, tracking the upstream BBC TAMS specification. Issues you raise on GitHub reach the people who can fix them.
Kubernetes is our day job
We are a cloud-native consultancy first. We design, build and support production Kubernetes platforms for organisations that depend on them, which is the same work a TAMOSS deployment asks for.
Platforms handed over, not held
Our delivery model is to build a platform, document it, and hand operational control to your team. See our Kubernetes as a Service platform for Siemens Digital Industries.
Pilot Partners
If you're considering TAMOSS for either a production workload, an outside broadcast, or a facility-wide deployment, we'd love to talk it through.
Get involved
Checkout the live Github repo and for all the latest TAMOSS updates, join our TAMOSS Slack channel in the Cloud Native Agile Production workspace
Common questions about TAMOSS.
Isn't Kubernetes expensive?
A common assumption, and one we'd rather meet head-on. The cost of Kubernetes scales with what you ask of it. A single-node TAMOSS deployment is cheap to run, and a local deployment is completely free. If you are scaling to a multi-region cluster, the costs are driven by the multi-region cluster, and the thin Kubernetes orchestration remains cheap. In other words, the orchestration layer doesn't impose the costs; they depend on the workload, the same way they would with any other infrastructure.
How does this compare to running TAMS on AWS?
The simple answer is TAMOSS is complementary, not competitive. AWS provides a serverless TAMS implementation. TAMOSS provides a Kubernetes-native version. If your workload is happy on AWS, run it there. If you need on-prem, hybrid, multi-cloud, or portable infrastructure, that's where TAMOSS earns its place.
Is this only viable for large deployments?
No. The open-source product runs on everything from a laptop to a full multi-region cloud deployment. If you need support with a larger-scale deployment, LiveWyer have professional services and a pilot offering as a great first validation step to build confidence.
What's the relationship with the BBC?
TAMS is an open API specification, stewarded by the BBC. TAMOSS is an independent open-source implementation by LiveWyer. We track the upstream API spec faithfully, with no proprietary extensions or API drift.
What license? Who maintains it?
TAMOSS is released under the Apache License, Version 2.0, with permissive use, modification, and redistribution, including in commercial products. LiveWyer maintains the project and welcomes community contributions through the GitHub repository, Slack engagement and regular meeting cadence.