Skip to main content

​
Overview

Lumafield’s cloud environment uses a usage‑based model so your team can scan and analyze as much as you need while staying within clear limits. You’ll see simple budgets for storage capacity measured in terabytes (TB) and an annual Token allocation for compute‑intensive actions. When you reach a storage limit, Voyager automatically moves projects between tiers to keep you within your plan. If you exceed your annual token allocation, no action will be taken, but we will adjust your plan upon renewal. If your organization is on the Pro or Enterprise plan, the usage UI is visible to everyone in your workspace. Legacy plans do not show these controls.
This article applies to both standard Cloud and GovCloud deployments of the Lumafield Platform.

​
Key concepts

Active storage (TB): Active projects are 3D Projects with a full CT scan and Reconstruction wherein new analyses and data can be authored. When a scan completes, the resulting project is Active and supports creating new data via Recipes and Voyager tools. Inactive storage (TB): Projects that have been automatically migrated out of the Active tier to optimize capacity when the Active TB budget is exceeded. Inactive projects remain available for viewing and sharing, but write operations are disabled until they are returned to the Active tier. Moving back to Active can take some time. Read‑Only projects: A Read‑Only project is a 3D Project with a full CT scan and Reconstruction wherein new analyses and data can no longer be authored. The full set of resulting Analyses, Data Objects, Meshes, Bookmarks, etc. remain available for inspection and sharing. Tokens (per year): Your annual allowance for compute‑intensive actions. Tokens reset each year on your contract anniversary. Token reset date: Typically the start date of your contract; Tokens refresh annually on this date. Pinned projects: Active projects that are explicitly kept in the Active tier. Pinned projects remain Active and are excluded from automatic migration to Inactive or Read‑Only while pinned. Use pins to prevent critical work from being archived automatically.

​
Where you see usage

  • Top bar in Voyager: All members (Editors, Viewers, Managers) see current usage against your Active TB, Inactive TB, and Token budgets.
  • Manager dashboard: Managers see detailed usage, limits, and the Token reset date for their organization.

​
How project migration works

When your organization is on Pro or Enterprise:
  1. Active → Inactive: Projects will automatically migrate from Active to Inactive when you exceed your Active TB budget. Migration happens in “least‑recently‑accessed” order.
  2. Inactive → Read‑Only: This is controlled by the Automatic Read‑Only Migration toggle. If enabled and your Inactive TB budget is exceeded, projects will migrate from Inactive to Read‑Only in least‑recently‑accessed order.
Notes:
  • Read-Only preserves all ROIs, bookmarks and analyses that have been made in that project. The project remains fully viewable and shareable in Voyager, but new analysis is not supported.
  • If you turn off the Read‑Only migration toggle, projects will not move from Inactive to Read‑Only automatically. Projects may still move from Active to Inactive when Active TB is exceeded.

​
Tokens

Tokens represent your annual allowance for compute‑intensive actions taken by your organization. Examples include larger analyses like reconstructions or bulk operations. Your annual Token allocation and reset date are visible to Managers in Voyager. When you reach your annual Token allocation, contact your Customer Success Manager to discuss options or wait til renewal to discuss.

​
Best practices for cloud storage

  • Size your Active TB budget for the subset of projects your team actively edits. Many teams plan for current work + near‑term reviews.
  • Use Inactive TB for the projects you want readily accessible but no longer edit every day. Active projects are automatically migrated to Inactive on a least recently accessed basis when your Active storage budget is exceeded.
  • Enable Automatic Read‑Only Migration to keep usage under control if your backlog grows.
  • If you have seasonal spikes, consider increasing budgets or scheduling migrations ahead of major pushes.

​
Example scenario

Your organization has:
  • Active TB: 10 TB
  • Inactive TB: 20 TB
  • Automatic Read‑Only Migration: Enabled
If you currently have 11 TB of Active projects, Voyager will automatically move about 1 TB (least‑recently‑accessed) from Active to Inactive. If your Inactive tier later grows beyond 20 TB, Voyager will move least‑recently‑accessed projects from Inactive to Read‑Only.

​
Glossary

  • Active (TB): Writable project tier. Editors can create new analyses and data.
  • Inactive (TB): Delayed access tier. Optimized for capacity; retrieval can be slower.
  • Read‑Only: View‑only project state.
  • Tokens (per year): Annual allowance for compute‑intensive actions. Resets on the contract anniversary.
  • Token reset date: The date your Token allocation refreshes (usually contract start).
  • Least‑recently‑accessed: The order Voyager uses to pick projects for migration between tiers.

​
FAQ

  • What happens if we turn off Automatic Read‑Only Migration?
    • Projects will not move from Inactive to Read‑Only automatically. Projects can still move from Active to Inactive when Active TB is exceeded.
  • Can Read‑Only projects be made editable again on cloud?
    • If there is need for this, Lumafield can attempt to restore Read-Only projects in cloud environements for a certain time. Talk to your organization Manager or Customer Success team about restoring write access.
  • What exactly consumes Tokens?
    • Tokens are used for compute‑intensive actions. The specifics depend on your contract and features enabled. Managers can monitor usage in Voyager and contact Lumafield for details. Reconstructions, especially with many corrections or with larger volumes are the primary token consumer.