Gcore Streaming treats one account as one shared workspace for live streams, VOD assets, API tokens, billing, and service limits. It does not split a single account into built-in development and production environments.
Account models
Select an account model based on whether the project needs logical organization or hard separation.
One account for small projects
Use one account when development and production assets do not require separate access boundaries and the same team manages both.
For VOD libraries, create directories to group uploaded videos and reduce operational mistakes. The directories guide shows the Customer Portal workflow, while the Directories API returns the directory tree for API-based workflows.
Directories organize VOD assets inside one account. They are not an access boundary for live streams, API tokens, billing, or service limits.
Two accounts for separate workflows
Use two accounts when development and production must have separate credentials, assets, and operational access. Create one for each workflow and generate a separate API token in each.
This model reduces the risk of development scripts changing production videos or live streams because each API token belongs to a different account. Billing must be active for both accounts when both run paid Streaming workloads.
Each account also has separate CDN delivery domain names, so development and production can use different playback URLs. This allows testing delivery settings, caching behavior, and custom CDN approaches without changing the production delivery path.
Account switching is available from one login when the user has access to multiple accounts. Use additional accounts to create and switch between accounts.
Three or more accounts for enterprise workflows
Use three or more accounts when the release process needs separate development, staging, production, or regional environments. Each account can have its own users, API tokens, assets, delivery settings, and billing setup.
Enterprise projects can combine multiple accounts with custom plans when commercial terms, committed volumes, support conditions, or service limits differ between environments. This model fits teams whose release process moves changes through development and staging before production. 
