> ## Documentation Index
> Fetch the complete documentation index at: https://link.datarelay.run/llms.txt
> Use this file to discover all available pages before exploring further.

# Use case: ConfigurationBundle safely

> Validate, diff, apply and export a reviewed v2.4 Server configuration change.

# Roll out reviewed policy with a ConfigurationBundle

**Outcome:** A Server administrator creates narrowly scoped network/service objects and an Internet Access WHITELIST in one validated configuration transaction, without directly editing internal files.

## Step 1 — confirm Server role and baseline

![Actual DRLink Server CLI status — verify Server role and plane-specific initial access behavior](https://mintcdn.com/data-relay/RzAl7zFhuZCRSIKj/images/cli-captures/server-status.png?fit=max\&auto=format\&n=RzAl7zFhuZCRSIKj\&q=85\&s=bfe6b188996c8ea2078dfe6c01145c28)

*Figure 1. Real Server CLI status: verify Server role and the different initial ALLOW/DENY policy modes before editing a bundle. Pre-configuration test capture; sensitive details masked.*

**Server shell:**

```bash theme={null}
sudo drlink system version
sudo drlink show status
sudo drlink system revisions
sudo drlink system export configuration /tmp/drlink-before.yaml
```

Keep the baseline privately, as exported config may include sensitive operational material. Do not commit the export to a public repository.

## Step 2 — write a complete desired-change bundle

On the **Server shell**, create **/tmp/drlink-allow-github.yaml** with this content. Replace the example source IP with the real **proxy-visible** source:

The YAML below illustrates the resource changes. First obtain `configurationBundle.sourceRevision` from a fresh `system export configuration <FILE>`, and copy **that field and its exact value** immediately below `context: server` in the file you will apply. Omitting it from a copied example does not bind apply to the revision you reviewed. Replace references such as `ubuntu-prod` with actual existing selectors.

```yaml theme={null}
configurationBundle:
  context: server
  networkObjects:
    - name: office-admin
      type: ip
      value: 203.0.113.10
    - name: github
      type: fqdn
      value: github.com
  serviceObjects:
    - name: https
      type: tcp
      port: 443
  internetAccess:
    mode: whitelist
    enforcement: enabled
    rules:
      - name: github-https
        source: office-admin
        destination: github
        service: https
        enabled: true
```

This is the **Server** bundle schema. Do not add **apiVersion**/**kind** or Agent-only **remoteServices** here. Resources omitted from the bundle remain unchanged, but existing Internet Access rules also remain unless deliberately changed. Review them before applying.

## Step 3 — validate and compare before mutation

![Real Data Relay Link CLI capture — Real configuration revision diff: compare the changes and sourceRevision before applying a bundle.](https://mintcdn.com/data-relay/RzAl7zFhuZCRSIKj/images/cli-captures/config-revision-diff.png?fit=max\&auto=format\&n=RzAl7zFhuZCRSIKj\&q=85\&s=092795979a6378b6e0eb5ae45b61f9e6)

*Figure 2. Real configuration revision diff: compare the changes and sourceRevision before applying a bundle. CLI output example; sensitive addresses and hostnames are masked.*

**Server shell:**

```bash theme={null}
sudo drlink test configuration /tmp/drlink-allow-github.yaml
sudo drlink system diff configuration /tmp/drlink-allow-github.yaml
sudo drlink show internet-access
```

Expected: syntax/context valid, an understandable change diff and no unintended broadening. If the source revision has changed since the export, **re-export** and reconcile the new state. A valid test is not permission to apply a stale bundle.

## Step 4 — apply the reviewed change

![Real Data Relay Link CLI capture — Real revision history: inspect previous set/unset operations and revision IDs before planned rollback.](https://mintcdn.com/data-relay/RzAl7zFhuZCRSIKj/images/cli-captures/configuration-revisions.png?fit=max\&auto=format\&n=RzAl7zFhuZCRSIKj\&q=85\&s=7297d568222a96916265ebea13b96e5e)

*Figure 3. Real revision history: inspect previous set/unset operations and revision IDs before planned rollback. CLI output example; sensitive addresses and hostnames are masked.*

After inspecting the security-impact confirmation and having the necessary operator authorization:

```bash theme={null}
sudo drlink system apply configuration /tmp/drlink-allow-github.yaml
sudo drlink show internet-access
sudo drlink system revisions
```

Expected: the new objects/rule appear and are effective for new connections; the same bundle applied again should result in **NO CHANGE** when state and revision permit. A Server bundle is atomic within **Server** context, not a distributed Server+Agent transaction.

## Step 5 — prove policy plus traffic

**Server REPL:**

```text theme={null}
test internet-access source office-admin destination github service https
system audit
```

From the actually approved protected host, configure the standard HTTP(S) proxy and test a real HTTPS Git or curl request using the [GitHub egress playbook](https://link.datarelay.run/use-cases/github-egress.md). A policy ALLOW result alone is not traffic E2E.

## Recovery and cleanup

If validation or apply rejects the bundle, **no partial configuration change** is expected; inspect the reported error rather than bypassing transaction guards. Compare the recorded revisions with `system diff <REVISION_A> <REVISION_B>` and plan a reviewed `system rollback <REVISION>` only if required. Avoid treating a blind rollback as risk-free: it can change current access. Keep exported files in protected storage and remove temporary copies after the approved work.

## Current behavior check — 2026-10-28

Carry sourceRevision from a fresh export into the reviewed change. A stale apply is rejected even if test/diff previously looked valid; re-export and reconcile before retrying. Same-state reapply can be NO CHANGE, but an old export is not a reusable force-overwrite mechanism.

[Current CLI inventory](https://link.datarelay.run/drlink/cli-reference.md) · [MCP compatibility](https://link.datarelay.run/reference/mcp-validation.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.