---
title: "ADR-016: Sidecar daemon option"
manual: "nr-vault"
version: "1.0"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-vault:adr-016-sidecar-option@1.0"
source: "Developer/Adr/ADR-016-SidecarOption.rst"
rendered: "2026-09-18T07:37:50+00:00"
---

# ADR-016: Sidecar daemon option {#adr-016-sidecar-daemon-option}

**Table of contents**

-   [Status](https://docs.typo3.org/permalink/netresearch/nr-vault:status@1.0)
-   [Date](https://docs.typo3.org/permalink/netresearch/nr-vault:date@1.0)
-   [Context](https://docs.typo3.org/permalink/netresearch/nr-vault:context@1.0)
-   [Decision](https://docs.typo3.org/permalink/netresearch/nr-vault:decision@1.0)
-   [Consequences](https://docs.typo3.org/permalink/netresearch/nr-vault:consequences@1.0)
-   [Alternatives considered](https://docs.typo3.org/permalink/netresearch/nr-vault:alternatives-considered@1.0)
-   [Related decisions](https://docs.typo3.org/permalink/netresearch/nr-vault:related-decisions@1.0)

## Status {#status}

Accepted

## Date {#date}

2026-01-12

## Context {#context}

FFI does not provide true isolation. If the threat model includes "PHP process
compromise", a separate process (sidecar/daemon) running under different OS
permissions can provide stronger separation:

-   Master key not readable by PHP process user
-   Narrower filesystem and network capabilities
-   Independent hardening and observability

We don't want to block MVP with sidecar complexity, but we must not paint
ourselves into a corner.

## Decision {#decision}

-   The transport abstraction ([ADR-012: SecureHttpClient API and transports](https://docs.typo3.org/permalink/netresearch/nr-vault:adr-012-secure-http-transports@1.0)) remains
    compatible with a future `SidecarTransport`
-   Request/response specs are designed to be serializable (e.g., JSON or binary
    framing) so that FFI and sidecar can share the same protocol shape
-   Sidecar mode is explicitly a Phase 3 candidate, not MVP scope

## Consequences {#consequences}

### Positive {#positive}

-   Preserves an upgrade path to stronger isolation without breaking consumers
-   Allows security-conscious customers to adopt a more robust deployment model
    later

### Negative {#negative}

-   Some design choices (spec framing, error taxonomy) must be slightly more
    disciplined early on

## Alternatives considered {#alternatives-considered}

### Commit only to FFI and ignore sidecar {#commit-only-to-ffi-and-ignore-sidecar}

Do not support a sidecar mode at all.

**Rejected**: too limiting for serious security requirements.

### Start with sidecar immediately {#start-with-sidecar-immediately}

Build sidecar mode from the start.

**Rejected**: slows down MVP and increases operational burden prematurely.

## Related decisions {#related-decisions}

-   [ADR-012: SecureHttpClient API and transports](https://docs.typo3.org/permalink/netresearch/nr-vault:adr-012-secure-http-transports@1.0) \- Transport abstraction (enables sidecar)
-   [ADR-013: Rust FFI preload-only mode](https://docs.typo3.org/permalink/netresearch/nr-vault:adr-013-rust-ffi-preload@1.0) \- FFI mode (alternative to sidecar)