Local studio work
A template-based Studio service supports private workspaces, editable pages, previews and explicit local publishing/version rollback. Separate local components support archive discovery and equipment planning.
One studio.
Several places to work.
The .Studio direction connects the places where work happens around the shared XDHD production model. A studio can combine local tools and private storage with hosted applications. Each tool and connection has its own supported scope.
The four roles in a Studio environment
Working machines
Author, prepare and preview.
The tools on a workstation do the work its host can support: editing, media preparation, visual recipes and local review.
Project context
Keep identity, meaning and references.
Projects and cartridges describe what the work is and how its parts relate. Participating local surfaces can share a selected graph; other representations need their own adapters.
Private storage
Keep the material the work needs.
Working files, selected media and archives can live on designated local or private storage. A project reference can remain useful when its media is not on the current machine.
Hosted services
Present, coordinate and deliver.
Selected websites, project surfaces and media services can run on hosted infrastructure. Connections to authoring, storage and publishing are specific to each implementation.
Small enough to stay close
Identity, project records, references, indexes and useful previews let a lightweight machine understand the work without every original media file.
The right material for the job
A working subset can include editable project documents and proxy media. Full-quality sources, dependencies and outputs have their own designated home and availability.
Knowing about an asset is different from having its bytes. Existing local intake can preserve originals, register references and make selected verified copies. General selective synchronization, proxy materialization and reconciled cross-machine writeback remain development work. Working storage, caches and independent backups need separate policies.
The cloud side
of the studio.
VPS2 describes a developing customer-controlled cloud studio pattern: infrastructure for chosen sites, services and private workflows. Portability and control are design goals. Existing shared infrastructure provides working examples, rather than a complete customer deployment.
Infrastructure in a box.
VPS2 is the pattern for a hosted studio environment: a place for chosen web applications, project services and the infrastructure that supports them.
Working machines and private media storage can remain alongside it. Which services run where is a deployment choice, with explicit connections between them.
VPS2 / hosted studio patternConceptual layers
Studio surfaces
A browser-facing place to reach the services chosen for a studio. Local Studio tools already include private workspaces and template-based page previews; broader hosted admission and shared identity are follow-on work.
Project views · sites · review surfaces
Applications + supported adapters
Each application supplies its own production capability and data boundary. Shared CORE components and HOST adapters provide connections where they have been implemented.
Chosen web apps · media services · explicit handoffs
Hosted infrastructure
The server and operational foundations beneath those applications. Deployment, storage, backups and restore responsibilities must be defined for each environment.
Application runtime · service data · scoped operations
Built in slices.
Growing as a system.
Local Studio tools and selected hosted services already provide useful pieces. The wider Studio experience is developing around them, with each new connection verified in its own host.
Selected hosted services
Existing deployment records cover selected websites and radio/media services on shared infrastructure. General customer Studio provisioning and a unified VPS2 control plane remain in development.
A portable studio environment
Customer-controlled deployment, unified provisioning, shared job dispatch and production synchronization are goals. Broad cross-host identity, storage and application connections still need implementation and acceptance.
“Studio in a box” describes the intended operating experience. Service scope, availability and deployment responsibilities will be defined for each supported environment as the offering develops.
An illustrative production path.
Prepare locally, choose the material you need, produce with a capable host, then review a deliberate handoff. These steps show how the roles fit; they are not one automatic distributed workflow.
Start with context
Choose a local project and register its sources. Keep project identity and provenance alongside the work.
Existing local staging; no implied cloud project creation.
Select the material
Use an explicit reference or a verified local copy for the task. Keep availability visible when other media stays elsewhere.
A reference is not downloaded media or a collected dependency set.
Work in a capable host
Prepare images, audio or video, or build visual recipes with the chosen tool. Review outputs in that host.
Capability and renderer support vary by tool and machine.
Review the next handoff
Choose what to retain, collect or present through a supported service. Preserve the distinction between local output and public delivery.
Commit, upload and publication remain explicit, separate operations.
The local preparation and selected-copy paths exist in bounded forms. Remote job dispatch, universal format interchange, automatic return and cross-host publication are not established by this example.
Follow the connections.
The Field Guide explains the vocabulary. The component overview shows the tools, shared logic and workflow paths behind it.