Skip to main content
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 environments or customer spaces, so separation comes from using several accounts or from labeling content inside one account. Two cases need separation: the sub-customers of a service that hosts videos and live streams for its own users, a video-sharing service for instance, and the environments of one team (development, staging, production). The first case is covered in Isolate sub-customers, and the second in Separate environments. Gcore enforces isolation only between separate accounts, while inside one account content can be filtered but not isolated. The diagrams show the difference. Separate accounts isolate sub-customers, while one account holds everything together and only labels it.

Isolate sub-customers

A service that hosts videos and live streams for its own sub-customers must decide where each sub-customer’s content lives and who can reach it. Gcore Streaming offers hard isolation through accounts and soft separation through labels.

One account for each sub-customer

Separate accounts are the only documented hard boundary between sub-customers. Each account has its own API tokens, billing, assets, service limits, and CDN delivery domain, so content, credentials, and costs of one sub-customer never mix with another. Use this model when sub-customers need their own credentials or invoices, or when content must never share a workspace. The cost is account management: every account is created and configured separately. A reseller setup, where Gcore creates sub-customer accounts under the service’s account, is available by arrangement. Contact Gcore support or the account manager to discuss it.

One account with client_user_id

Live streams and videos are not isolated inside one account, but they can be filtered by a sub-customer identifier. Two optional attributes of streams and videos carry it:
  • client_user_id: An integer that identifies the sub-customer in the application’s own system.
  • client_entity_data: A string for any other metadata of the stream or video.
Gcore stores both attributes, returns them in API responses and webhooks, and doesn’t enforce anything with them. The video list can be filtered by client_user_id, and so can the watching duration and unique viewer statistics of live streams and videos, which gives per-sub-customer reporting for those two metrics. Views, geography, browsers, operating systems, and the billing reports are calculated for the whole account and can’t be split by sub-customer. Gcore doesn’t check the label, so the application backend enforces the separation: it holds the API token, sets client_user_id on every stream and video it creates, and applies the sub-customer filter on every list and statistics request. Keep the API token on the backend only, because anyone with the token sees every sub-customer’s content.

Permissions

Roles and API tokens apply to the whole account. Portal user roles include Administrators, Engineers, and purge-only roles, and an API token gets one role for each product, Streaming included. The documentation doesn’t describe limiting a role or token to one directory, stream, video, or sub-customer.

Viewer access

Access of end viewers to a video or stream is controlled separately from the account model:
  • Video secure tokens restrict playback to signed links with an expiration time and optional IP binding. Secure tokens and CDN access policies by country, referrer, or IP require a custom CDN resource on a paid CDN tariff, because the default streaming delivery domain doesn’t support them.
  • AES-128 encryption protects VOD content with a key served by a key server.

Separate environments

Select an account model based on whether the project needs logical organization or hard separation. The diagram shows the three-account model, where each environment is a separate account and a release moves the same workflow from one account to the next. Two accounts work the same way without the staging account.

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.