Skip to content

Replicove · Developer documentation

Your cluster’s tools. A fresh place to test.

Recreate selected operators, Helm components, and configuration in a disposable vCluster. Give your integration tests, developers, and agents a familiar environment—with a lifetime you control.

Install with Helm Download or build the CLI Use YAML Start with the CLI Try the ten scenarios

Experimental portable alpha

These instructions target v0.3.0-alpha.2. All 16 exact-source CI jobs and all 11 release jobs passed. Validation records the release, download checks and separate scenario evidence. Production and cloud certification remain future work. See tested behavior and remaining work.

Choose what matters

Administrator grants, namespace and label selectors, dependency planning, explicit secrets, and application overrides.

Selection guide →

Create a place to test

Replicove provisions a pinned vCluster, or connects to one an administrator has already registered.

Runtime choices →

Finish with cleanup

Bounded guest credentials, explicit refresh, ownership tracking, and cleanup on deletion or TTL expiry.

Lifecycle guide →

One API, two ways to use it

The CLI submits Kubernetes resources. You can use those same resources directly with kubectl, GitOps, or a Kubernetes client:

Resource Who manages it Purpose
ReplicaGrant Host administrator Authorize sources, secrets, runtimes, TTL, and access roles
ClusterReplica Developer, CI, or agent Select configuration and request a temporary replica
ReplicaAccess Authorized credential consumer Request a bounded guest credential
ReplicaMirror Developer, CI, or agent Select workload/PVC copies, schedule resets, and bound their lifetime
ReplicaMirrorRun Developer, CI, or agent Request an immutable manual Sync or saved-revision Reset
ReplicaExperiment Authorized test runner, developer, or agent Apply bounded faults to owned test workloads and verify rollback

TestRecipe and ReplicaPool are local CLI documents, not additional CRDs.

The YAML quickstart covers the operator installation, the core replica resource types, connecting with kubectl, and verified cleanup. You do not need the Replicove or Helm CLI for that workflow.

What a replica means

Replicove recreates selected, authorized Kubernetes desired state. It strips host identities, resolves known dependencies, applies your mappings and overrides, and creates new objects in the guest. A source capture is a series of API reads, not an atomic etcd snapshot.

The guest has its own API server and object identities. With the current shared-worker profiles, workload pods still use host compute and networking. The optional workload mirror module copies explicitly granted CSI-backed data into independent writable generations. Replicove does not automatically recreate cloud accounts or every managed-cluster feature. Compatibility and limits explains the boundaries.

Find the right guide

Start with the feature map for every implemented capability, its guide, and its limits. To add optional data copies to an existing deployment, use enable mirroring later.

The ten executable scenarios put these features together in disposable integration labs. Every documented variant uses the pinned public release, verifies expected outcomes, and checks cleanup. The same entry points run in the documentation scenario workflow; each page explains the operations and their limits.

Built in public by Nimesh Builds. Replicove is an independent Apache-2.0 project; it is not affiliated with the vCluster maintainers.