Architecture

Local-first. Intranet-only. Fail-closed.

Three properties that define ntkDeploy's operational model. No cloud dependency. No remote state. Every decision made locally, every deployment verified before execution.

Data Layer

SQLite-first Data Model

All application state lives in a single local SQLite database managed by Drift. There are no cloud accounts, no login screens, no sync services. The database is the source of truth for every entity ntkDeploy manages.

Table Purpose
profiles ntkDrive configuration profiles — schema-validated JSON payloads with version history
providers Policy Manager connection settings including mTLS certificate material
assignments Mapping of profiles to device groups for scheduled deployment
device_groups Named collections of UNC target paths
device_ownership Person-to-device-path mapping; required for ownership gate
people Person registry — name, identifiers, enrollment status
enrollment_requests Pending device enrollment queue from Policy Manager
abac_templates Cached ABAC attribute definitions for offline form population
audit_log Append-only record of every state-changing action

Startup

Boot Sequence

ntkDeploy initialises all dependencies synchronously during bootstrap before the UI frame renders. The Policy Manager client is the only component deferred — it requires provider settings that may not be configured on first run.

Build Pipeline

Configuration Build Pipeline

When the deploy wizard confirms all gate conditions, the config build service assembles a per-device artifact. Each artifact is self-contained — it includes the resolved configuration, the policy snapshot, and the peer identity for that specific device.

ConfigBuildService.buildArtifacts() 
input:        Profile + Assignment + PolicySnapshot + DeviceList
              ↓
per_device:   resolve sources/overrides for each UNC path
              ↓
embed:        snapshot hash + peer identity + profile version
              ↓
validate:     schema conformance check on final payload
              ↓
output:       BuildArtifact[] — one per device path

Sources & Overrides

Each profile field can reference a Provider as a data source or declare a static override. During build, sources are resolved against the provider's current values. Overrides take precedence. The final JSON payload reflects what will be written to the device path.

Snapshot Embedding

The policy snapshot is fetched immediately before artifact construction. Its cryptographic hash is embedded in the artifact header. This creates a tamper-evident link between the deployed configuration and the ABAC policy state that authorized it.

Transport

UNC/SMB Deployment Model

ntkDeploy deploys configuration artifacts to Windows devices via standard UNC paths using SMB. The deploying machine's Windows session identity provides share access — no credentials are stored or handled by the application.

  1. 01

    Validate UNC paths

    Each path in the device group is validated for correct UNC format (\\server\share\path) before the wizard proceeds. Malformed paths are rejected at entry time, not at deployment time.

  2. 02

    Build per-device artifacts

    The build pipeline assembles one artifact per device path. Artifacts are held in memory — they are never written to the administrator's local disk.

  3. 03

    Write via pass-through auth

    Each artifact is written to its UNC target path using the Windows session's credentials. ntkDeploy makes no credential decisions for SMB — access is controlled entirely by share ACLs and domain policy.

  4. 04

    Record outcome

    Each write result — success or failure — is recorded in the audit log with the device path, timestamp, and snapshot reference. The deployment wizard displays per-device status in real time.

Verification

Verification Layers

The deploy gate evaluates these four checks in sequence. All four must pass. There is no soft-fail mode — a failed check prevents deployment entirely.

Check What it verifies Gate behaviour on failure
Connectivity Gate Policy Manager endpoint reachable; /capabilities and /readyz return 200 Deploy button disabled; error banner shown with endpoint URL
Ownership Mapping Every device path in the assignment has an assigned owner in the people registry Deploy blocked; CTA shown to assign missing owners
Preflight API preflightBulkVerify returns no blocking findings for any device in the assignment Deploy blocked; blocking findings listed per device
Snapshot Retrieval Current policy snapshot fetchable from Policy Manager; cryptographic hash verified Deploy blocked; snapshot error code shown with retry option
Full security model