Self Managed Storage

Self Managed Storage lets your organization keep every file, document, and attachment created in Novantra inside an object storage container that you own and control. Instead of those objects living in storage that Novantra runs for you, they live in your account, in your region, under your policies.

What it is

By default, files uploaded into Novantra are written to storage operated by Novantra. Self Managed Storage replaces that default with object storage of yours.

You provide the object container. You set the provider and region. You hold the credentials. Novantra reads and writes through it for you, but the data itself never leaves your control boundary.

In Cloud, this choice is evaluated against the workspace’s selected regional cell. Storage is a material residency surface, so strict policies may block activation when the provider region does not align with the selected cell. Non-strict policies may allow a mismatch with a clear warning and recorded acknowledgement.

Why use it

Most organizations turn this on for one of these reasons:

• Data residency. Files must live in a specific country, region, or account for legal or contractual reasons.
• Your own backup and retention rules. You already have lifecycle policies, object lock, replication, or backup tooling, and you want files Novantra creates to follow the same rules everything else of yours follows.
• Audit and visibility. Your security team wants storage access logged inside your own audit trail instead of a vendor report.
• Key control alignment. If you also use Self Managed Secret Keys, holding the storage in your own account makes the custody story consistent end to end.
• Exit and portability. If you ever leave Novantra, the file data is already in storage you own. There is no export step for the files themselves.

What you provide

Cloud customers provide:

• A dedicated AWS S3, S3-compatible, or Azure Blob object container for your organization. Sharing one object container across organizations is not supported.
• A way for Novantra to authenticate to the object container. The cloud BYO setup currently uses delegated AWS role credentials for AWS S3/S3-compatible bindings; Azure Blob managed-cell storage uses managed identity or provider-managed credentials.
• The provider region and any required policy conditions.

On-prem installations have the same customer-managed object storage option plus the ability to use a local filesystem path on the install host. Static encrypted credentials are accepted in on-prem because some private deployments do not have a delegated identity path.

You do not need to give Novantra raw secrets, root account credentials, or write access to anything outside the chosen object container.

How activation works

Setup happens in your workspace settings under Storage, and runs in three deliberate steps:

1. Add a binding. You enter the object container details and the credential reference. Nothing changes yet. Existing files keep going to wherever they are today.
2. Validate. Novantra runs a probe against the binding: it confirms the credential resolves, the object container exists, and that it can write, read, list, and delete a small test object. The probe also checks the encrypted-object round trip used by the rest of the product. If anything fails, you get a clear, redacted reason. Raw provider errors and credentials are never shown back to you, your team, or support.
3. Activate. Once validation passes, you flip the binding active. From that point onward, every new file Novantra writes for your organization goes to your active object storage binding.

You can re-run validation at any time, including on the active binding. A background sweep also re-validates the active binding periodically and surfaces any drift (such as a credential that has been rotated away).

What happens day to day

• New files are written to your active object storage binding.
• Existing files keep being read from wherever they were originally written. If a file was created before activation, Novantra remembers which binding holds it and reads from there. You don’t lose access to anything.
• Deleted files are deleted from whichever binding actually holds them.
• Disabled bindings remain readable for the files already in them, but they will never receive a new write.

Moving older files into your object storage

If you want files created before activation to also live in your active object storage binding, you can run a one-shot migration. A migration:

• always requires you to run a dry-run first. The dry-run tells you how many files are candidates and what would happen, but moves nothing.
• when you run it live, copies each file into your active storage binding, verifies the copy by checksum, and then updates Novantra’s record to point at the new location.
• never deletes the original copy. If you want to remove the source copies later, you do that yourself in the source account, on your own schedule.
• never falls back to Novantra-managed storage if your active binding is unreachable mid-run. It stops cleanly and you can retry.

Fail closed behavior

This is intentional. The whole reason for Self Managed Storage is that the data stays in your account, on your terms. If we silently fell back to platform storage during an outage of yours, that promise would be broken without you knowing.

When the active binding is unavailable, file operations for your organization fail with a clear error and are recorded as a security event in your operational evidence. As soon as the binding is reachable again, operations resume automatically.

Limits at a glance

Related

• Cloud Regions & Residency - how selected cells, storage, backups, keys, domains, and email compose into a residency posture.
• Self Managed Secret Keys — hold the encryption keys for your data in your own KMS, in addition to (or independently of) self-managed storage.