Struct InnerDoorPlan 

pub struct InnerDoorPlan {
    pub service: String,
    pub mounts: Vec<InnerDoorMount>,
}

A service’s inner door, as configuration — everything but the addresses.

Fields

service: String

Service name, for error messages and the workload name.

mounts: Vec<InnerDoorMount>

Mounts in declaration order. Precedence is PathRouter’s (longest mount wins), not this vector’s, so the order is presentational.

Implementations

impl InnerDoorPlan

pub fn units(&self) -> Vec<DeployedUnit>

Every distinct unit this door proxies to, in a stable order. What a caller resolving addresses has to answer for.

pub fn routes_file( &self, address: impl Fn(&DeployedUnit) -> Option<String>, ) -> Result<String>

Render the JSON passway reads, resolving each unit to its address.

address is placement-time knowledge — which node the unit landed on and which port kamaji gave it — so it arrives as a closure rather than as config. Returning None from it is refused rather than skipped: a mount whose upstream could not be resolved would be dropped from the table, and the door would then serve that path from whichever shorter mount matched — the root, usually — which is a wrong answer wearing a 200.

impl InnerDoorPlan

pub fn workload_name(&self) -> String

The workload name / mesh identity for this service’s inner door.

pub fn routes_path(&self) -> PathBuf

Where this door’s route table is materialized on the node.

pub fn listen_port(&self) -> u16

This door’s loopback port — listen_port of the service name.

pub fn unit_ident(&self, unit: &DeployedUnit, bundle_ident: &str) -> String

The mesh identity whose ready service record carries unit’s address.

The two arms come from different places on purpose, and neither is derivable from the other. A bundle’s ident is a mirror fact — BundleSlot::workload_name, which a slot may rename with name = "…" — so it is handed in. A workload-tier component has no slot to rename it, so its ident is derived (component_workload_ident).

pub fn resolve_addresses( &self, bundle_ident: &str, lookup: impl Fn(&str) -> Option<String>, ) -> BTreeMap<DeployedUnit, String>

Resolve every unit to a host:port, given a way to look an address up by mesh identity.

The step between units and the address closure routes_file and workload take: those two ask “where is this unit”, this answers it from a discovery read. Split out rather than folded in so the identity mapping stays testable without a fleet.

A unit with no answer is simply absent from the map — the refusal lives in routes_file, which is the single place a missing address is reported and which already explains why a dropped mount is worse than a failed apply.

pub fn workload( &self, listen_port: u16, address: impl Fn(&DeployedUnit) -> Option<String>, ) -> Result<Workload>

Render the supervisable workload: a passway process serving this service’s mount table on loopback.

Cleartext, and the invariant that makes it safe

PASSWAY_TLS_MODE=plaintext (operator call, 2026-09-09 — see passway::tls::parse_listener_tls_mode for the full argument). The short version: no CA issues for 127.0.0.1, so “TLS everywhere” here means a self-signed leaf plus a way to switch OFF upstream certificate verification on the public door — a real trust-boundary knob traded for encrypting a hop that never leaves the loopback interface.

This function cannot violate that invariant even if listen_port is wrong, because it binds 127.0.0.1 literally and passway refuses the mode on anything else. The bind is not a parameter.

Why listen_port is an argument

It is placement-time knowledge, exactly like the upstream addresses: which port is free is a property of the node, not of the config. The caller allocates and passes it, so this stays a pure function of (plan, port, addresses) and is testable without a node.

The route table travels IN the spec

Not written beside it: WorkloadSpec::files makes the table and the process that reads it one deploy rather than two, so a redeploy cannot leave a door serving a stale table. Only kamaji’s native backend materializes those; every other backend refuses the spec by name rather than starting the door against a file that is not there.

Why Workload::Container and not a new Workload variant

TenantPasswayWorkload is a typed variant, so the precedent for one exists — but it earns that by carrying config kamaji itself must act on (a domain to match, a PEM pair to re-read on every cold start, an idle TTL to reap against). An inner door carries none of it: its entire configuration is an argv, three env vars and one file, all of which WorkloadSpec already expresses. A variant would buy nothing but exhaustive-match churn in peer-owned kamaji-proto, which is the trade R572-F1 already made and recorded.

Trait Implementations

impl Clone for InnerDoorPlan

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for InnerDoorPlan

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for InnerDoorPlan

impl PartialEq for InnerDoorPlan

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for InnerDoorPlan