Studios — how your storage is organised and shared

What a studio is: a slice of your storage pool with its own access boundary. How allocation works, how sharing scope works, and how a BYOS studio differs.

A studio is a slice of your storage pool with its own access boundary. One account can hold several, and a BYOS studio keeps its storage on a bucket you control rather than in the hosted pool.

What a studio is

A studio is a named slice of your account's storage pool, with its own access boundary. It is not a separate account, a separate subscription, or a customer type — every PhotoLog account uses studios, because a studio is simply how you decide who sees what.

One account can hold several studios at once, each drawing from the same pool and each controlling its own sharing scope. A studio is the boundary; the pool is what it draws from.

A worked example

Say your plan gives you a 1 TB storage pool. You could allocate 400 GB to a studio you share with your family, 500 GB to a studio you share only with your spouse, and keep 100 GB in a personal studio only you can see. That is three studios, one pool, and three different answers to "who can see this."

A storage pool is divided into studios — here, a 1 TB pool split into a 400 GB family studio, a 500 GB studio shared with a spouse, and a 100 GB personal studio only the account holder can see. Each studio is an access boundary over its own slice of the pool. A BYOS studio is drawn separately because its storage lives in a bucket the customer supplies: it does not draw from the pool at all, though it still counts against how many BYOS studios the account's plan allows.

Allocation: the pool is the quota, the studio is the boundary

Your plan sets the size of your pool. How that pool is divided across your studios is yours to decide, and you can change it later — resizing a studio moves capacity between studios without moving photos. What a studio's allocation controls is how much of the pool that studio can use, not who else can see it; that is a separate setting, described next.

This is why a studio is not a plan, and not an account tier: two studios under one pool can hold very different amounts, be shared with entirely different people, and still both draw from the same underlying quota. See pricing for how pool size varies by plan.

Access and sharing

Who can see a studio's contents is a property of the studio, not of an individual photo or album inside it. Add someone to a studio, and they see what's shared in that studio; leave them out, and they don't. A personal studio with nobody else added is exactly that — a slice of your pool nobody else has been given access to.

This page describes the sharing boundary as a product setting: who has been added to a studio. What PhotoLog's own systems can technically read from stored media is a different, narrower question, answered onhow encryption works — the two are related but are not the same claim, and this page does not restate that one.

BYOS studios

A BYOS studio is a studio whose storage you host yourself, in a bucket you connect and control, instead of PhotoLog's own storage. A BYOS studio's storage does not draw from your pool at all — allocating 0 GB to it from the pool is normal, not a mistake, because its capacity comes from your own bucket instead.

There's a separate limit on how many BYOS studios you can create, though: separately from the pool, your plan sets a cap on how many of your studios may run in BYOS mode. How many depends on which plan you're on — some plans allow none, others allow one or more. Seebring your own storage for how to connect a bucket and what connecting one does and does not do to what's already in it.

How we verified this

The mechanism described above — one pool, several studios each with their own allocation, a BYOS studio exempt from the pool but capped by a separate per-plan limit — is drawn from PhotoLog's own engineering records: the storage-pool allocation system (an append-only allocation ledger plus the enforced ceiling it derives), and the per-studio BYOS mode and its plan-level entitlement column, both read directly from the project's planning and specification documents rather than taken from a summary.

One thing found while reading those records and not carried onto this page: the specific progression of how many BYOS studios each plan tier allows was not settled in what we could verify — the mechanism (a per-plan cap) is real and enforced in the schema, but we found only two example values in the current catalogue rather than a full published schedule, so this page states that the cap varies by plan without naming a specific number per tier. A formal, hash-verified citation for these claims could not be completed in this session — see this phase's own summary for the full path-level detail and the reason.