Importing and syncing secrets

If your secrets already live in 1Password or Bitwarden, there are two ways to get them into Reoclo, and they answer different questions.

	Import	Sync
Runs	once	on a schedule
Afterwards	the secrets are yours to edit	the provider stays the source of truth
Imported secrets are	normal, editable	read-only until detached
Use it to	migrate off the other tool	keep using the other tool

Import if you are moving. Sync if you are not — for example, when another team owns the values and you just need them where your deploys can reach them.

Both are one-way. Reoclo never writes back to your provider.

Importing once

An import reads entries from a provider and writes them into one secret project as ordinary secrets. Once it lands, there is no ongoing relationship: the secrets are versioned and editable like any other.

From the dashboard

Open a secret project, choose to import from a provider, and paste a provider token. Reoclo verifies it, shows you what it can see, and writes the entries you select into the project. The token is used for the import and is not kept unless you turn it into a sync connection.

From the CLI

The CLI import works differently, and the difference matters: it runs on your machine and drives the provider’s own CLI, so the values never travel through Reoclo’s servers on the way in. That also means the provider’s CLI has to be installed and signed in.

reoclo secrets import --from onepassword --project payments-production --dry-run

Source	Needs	Authenticated by
onepassword	the op CLI on your PATH	your existing op sign-in
bitwarden	the bws CLI on your PATH	BWS_ACCESS_TOKEN in your environment

Scope it, and dry-run it

Without --op-vault or --bws-project, an import reads every entry the provider CLI can see. Against a personal 1Password sign-in that means every vault on your account — often hundreds of entries you did not mean to copy into a project.

Always start with --dry-run, which reports exactly how many keys would be written and writes nothing.

reoclo secrets import --from onepassword --project payments-production --op-vault Engineering
reoclo secrets import --from bitwarden   --project payments-production --bws-project payments

See reoclo secrets import for every flag.

How keys are named

A provider entry has a title and fields; a Reoclo secret has one key. The key is built as ITEMTITLE_FIELDLABEL, uppercased, with runs of non-alphanumeric characters collapsed to _:

Provider entry	Field	Becomes
Stripe (live)	api key	STRIPE_LIVE_API_KEY
payments-db	password	PAYMENTS_DB_PASSWORD

Colliding keys get _2, _3. One-time-password fields, note fields, and empty values are skipped — they are not secrets your apps can consume.

Derived names are rarely the names your app wants. Expect to rename after importing, or set the key explicitly when configuring a sync connection.

What stops an import

An import writes nothing at all if the source has two entries that derive the same key — it cannot decide which wins, so it asks you to.

By default it also refuses if any key already exists in the target project, listing them. Pass --skip-existing to import the rest and leave existing keys untouched. If a large import fails partway, the message says how many landed; re-running with --skip-existing resumes.

Syncing continuously

A connection keeps a project fed from a provider. You give it a provider credential once, choose what to sync and where, and Reoclo reconciles on a schedule.

1. Add a connection

   From the Secrets area, add a 1Password or Bitwarden connection and give it a service-account or access token.

   The token is encrypted and stored; it is never returned by the API, shown in the UI again, or written to a log. Give it the narrowest read-only scope your provider allows.

   For Bitwarden, pick the right region — US is the default.

2. Choose what to sync

   For 1Password, browse vaults and select the specific items and fields you want. Only what you select is synced. You can override the derived key so a secret arrives under the name your app actually expects, rather than ITEMTITLE_FIELDLABEL.

   For Bitwarden, select the Secrets Manager projects to pull from.

   Browsing reads metadata only — titles, labels, ids. Values are read solely when a sync runs, in the background, and are never sent to your browser.

3. Pick a target project and cadence

   One connection feeds one secret project. Choose hourly, every six hours, daily, or manual — manual meaning it only runs when you click Sync now.

   Point different connections at different projects rather than merging several providers into one; it keeps “where did this come from” answerable.

4. Let it reconcile

   Each run creates new secrets, adds a version where a value changed, and leaves unchanged ones alone. Values only ever exist in the background worker — they are not logged, and audit entries record counts and key names, never values.

Synced secrets are read-only

A secret that a connection owns is marked as synced and cannot be edited, rolled back, or deleted in Reoclo. The provider is the source of truth, and letting you edit locally would just mean your change disappears at the next sync.

To take ownership, detach it. It becomes a normal secret, keeps its current value and history, and the connection stops managing it. Detaching is a one-way door — re-syncing would create it again alongside.

When something disappears upstream

If a secret vanishes from the provider, its Reoclo secret is marked orphaned by default and kept. It still resolves; it just is not being updated any more.

Turn on pruning and orphans are deleted instead. That keeps the project honest, at the cost of a deploy breaking if an app referenced a key someone deleted upstream. Pruning only ever touches secrets that this connection created — manual secrets and other connections’ secrets are never affected.

Leave pruning off unless you want the provider to be able to delete things in Reoclo.

If a sync fails

The connection records the error and keeps its schedule; a failure does not stop future runs and never crashes the sync. A revoked or expired provider token is the usual cause — check the connection’s last error, replace the token, and use Sync now rather than waiting.

Secrets already synced keep their values while a connection is broken. A sync that cannot run leaves the last good values in place rather than emptying them.

Next Steps

• Secrets Manager — projects, versions, and grants
• reoclo secrets — the CLI import
• Injecting secrets into CI — use what you just imported
• Environment variable references — wire it into an application