Self Managed Storage

Self Managed Storage lets your organization keep every file, document, and attachment created in Novantra inside a storage bucket 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 a storage bucket of yours.

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

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 (for example AWS CloudTrail) 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 S3 or S3-compatible bucket for your organization. Sharing a bucket across organizations is not supported.
• A way for Novantra to authenticate to the bucket. The recommended option is a delegated AWS role that Novantra can assume; long-lived access keys are not accepted in the cloud setup.
• The bucket region and any required policy conditions.

On-prem installations have the same options 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 role-assumption path.

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

How activation works

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

1. Add a binding. You enter the bucket 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 bucket: it confirms the credential resolves, the bucket 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 bucket.

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 bucket.
• Existing files keep being read from wherever they were originally written. If a file was created before activation, Novantra remembers which bucket holds it and reads from there. You don’t lose access to anything.
• Deleted files are deleted from whichever bucket actually holds them.
• Disabled bindings (older buckets you have replaced) remain readable for the files already in them, but they will never receive a new write.

Moving older files into your bucket

If you want files created before activation to also live in your bucket, 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 bucket, verifies the copy by checksum, and then updates Novantra’s record to point at the new location.
• never deletes the original copy in v1. 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 bucket 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 bucket 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 bucket is reachable again, operations resume automatically.

What’s not included in v1

These items are scoped out of the first release and tracked as separate work:

• Routing different kinds of files to different buckets (one bucket per purpose).
• Browser uploads going directly to your bucket without passing through Novantra.
• Provider-specific automated lifecycle, retention, and object-lock orchestration (you still configure those yourself on the bucket; Novantra surfaces evidence where the provider exposes it).
• Legal hold orchestration.
• Customer-side malware or DLP scanning delegation.
• Bulk cleanup of files left behind in older, disabled bindings.

Limits at a glance

Related

• Self Managed Secret Keys — hold the encryption keys for your data in your own KMS, in addition to (or independently of) self-managed storage.