Skip to content

Glossary

Terms used across the BCDock platform. The two most important - environment and pool - are CRITICAL because they're often confused with each other or with VM-shaped things from other platforms.

Environment

A Docker container running Business Central. Has a name, a BC version, a country localisation, an https://...bcdock.io/BC/ URL, and a billing meter. You create, hibernate, resume, and delete environments. They are the unit of work.

You manage environments through the portal, the CLI (bcdock env *), or the API. You do not manage the underlying VMs - that's the platform's concern.

Pool

An Azure VM hosting 2-9 environments. We operate pools; you don't. Pools are never stopped - they always have a public FQDN, Traefik fronting them, and capacity for new environments. The autoscaler creates pools when capacity is tight and tears them down when they're idle.

Each pool is locked to one combination of: BC version × country × artifact-type. An env can move between pools of the same combination (e.g. cross-region resume); it cannot run on a pool of a different combination.

Pool state inspection is staff-only via internal tooling, not exposed in the public bcdock CLI.

Company

A billing entity. One company per customer. All your environments belong to a company; that company gets the bill.

If you're a member of multiple companies (consultant, support engineer, agency staff), bcdock companies switch <id|name> changes which one new commands run against.

Active

An environment is active when its container is running and addressable at its URL. Active time is metered per-second against your subscription's active-rate cap or PAYG hourly rate.

Stored / Hibernated

An environment is stored (the billing term) or hibernated (the operational term - same state) when its container has been gzipped to blob storage. The pool slot is freed. Billing drops to the flat A$25/month stored rate. State (data, extensions, configuration) survives - resume any time and it's back exactly as you left it.

Hibernation

The act of moving an env from running to hibernated. ~1-3 minutes for a typical env. Triggered by bcdock env hibernate, the portal Hibernate button, or auto-hibernate when a trial active bucket is exhausted.

Resume

The act of moving an env from hibernated back to running. ~1-2 minutes on a warm pool of the same combination. Cross-major-version resume requires --version <ver> confirmation.

Pre-warmed environment

An environment that was created ahead of time on a pool slot, sitting in a pending-assignment state. When a customer requests a new env matching the same combination, we assign the pre-warmed one to them - bypassing the typical create wait. Silent optimisation; there's no "pre-warmed" status surfaced in the public API.

Draining

A pool state. Draining pools serve their existing environments but won't accept new env allocations. Used when the pool's BC version is being phased out - existing customers stay running until they migrate or hibernate; new customers go to the active version's pool.

Template (planned, H2 2026)

A hibernated environment with identity detached. Lets you instantiate new envs from a saved baseline (training, demos, client setups) at the flat stored rate. Same blob mechanics as hibernation; identity rewrite happens at clone time.

Cloning (planned, H2 2026)

Copy an environment's state into a new environment with a fresh identity. Built on the hibernation primitive - clone = hibernate + blob copy + restore-with-new-identity.

API key

A long-lived (bdk_…) credential the CLI uses for authentication. Scope-bounded, mintable in the portal, no refresh-token machinery. The right shape for agents, CI, and daily CLI use. See API keys.

JWT

A short-lived (15 min access + 7 day refresh) credential issued by the OTP exchange or the portal session. Implicitly carries platform_role for @bcdock.io operators. Useful for interactive admin sessions; not the right shape for agents.

Scope

A grant attached to an API key. Standard set: env:read, env:write, usage:read. Operator-only: admin. See API keys.

BCDOCK_TOKEN

Environment variable the CLI reads first when looking for credentials. Wins over stored credentials. The right shape for ephemeral processes (CI, agents) - never writes to disk.

Pool agent

A Windows executable running on each pool VM. Manages container lifecycle and exposes a small HTTP API to the platform (over Traefik). Customer-invisible.

Container agent

A Windows executable injected into each BC container. Handles container-side concerns - log forwarding, health probes. Customer-invisible.

Generic image

A VM image at the OS-installed-and-configured stage: Windows + Docker + BcContainerHelper, no BC artifacts cached. The first half of the 2-stage image system.

Versioned image

A VM image at the BC-cached stage: generic image + BC artifacts for one specific version × country. Pools deploy from versioned images. Naming: bcdock-vm-bc{ver}-{country}-{timestamp}.

Pool family

The set of pools sharing one combination of BC version × country × artifact-type. The autoscaler manages pool counts within a family; envs can move between pools within a family freely.

SAS URL

Azure Storage Shared Access Signature. Time-limited signed URL granting access to a single blob. We use SAS URLs for hibernation backup snapshots (operator-only; envelope-signed for the platform's use) and for data export downloads (24h TTL, customer-facing).

Provisioning logs

A platform-managed log stream keyed by env ID. Captures every stage of create / hibernate / resume / delete operations with structured fields. Excluded from the LAW-004 data export - it's operational telemetry, not personal data.

Soft delete

Both blob storage (Azure-level, 7d recovery) and our DB (deleted_at column) implement soft delete. After the recovery window expires, hard-purge runs and the row/blob is unrecoverable. See account-deletion for the deletion-flow specifics.

Anonymise-in-place

Our approach to GDPR Art. 17 / APP 11 erasure. Instead of cascade-deleting an anonymised user's rows (which would destroy FK integrity, audit trails, and financial records), we overwrite the User row's PII fields in place and leave referenced rows intact - they now point at an anonymous row. See account-deletion.