SealPort

sealport.cc

Encrypted backup CLI.

SealPort is an all-Rust backup command being built for owned, inspectable, scriptable backups with client-side encryption and boring restore paths.

View sourceRead project status
Command
sealport
Mode
CLI only
Backends
Local + S3 target
planned operator flowstdout stays machine-readable
$ sealport init s3://company-backups/laptops
$ sealport backup ~/Documents --tag laptop --jsonl
{"event":"backup.started","repository":"redacted"}
{"event":"backup.finished","snapshot":"planned"}
$ sealport restore latest ~/restore-test

Current status

Pre-v1 foundation, honest by default.

The Rust workspace, CLI shell, config/output contracts, initial crypto primitives, storage abstractions, and this public homepage exist. The backup and restore engine is still under construction.

ImplementedCLI foundation

version, completions, config precedence, JSON, JSONL, golden tests

ImplementedCrypto groundwork

master keys, passphrase unlock, subkeys, authenticated envelopes

ImplementedStorage groundwork

local backend, S3-compatible backend, fake store, capability model

Not done yetBackup engine

snapshot creation, restore pipeline, check, forget, prune, v1 release artifacts

Command contract

Built for shells, logs, runbooks, and restore drills.

01

Stdout is data

Human progress and diagnostics stay on stderr so scripts can trust stdout.

02

JSON and JSONL surfaces

Single-document output for state, event streams for long operations.

03

Dry-run destructive work

Forget, prune, and other destructive commands are planned around explicit dry runs.

04

Exit codes are part of the API

Failure families are documented before v1 and treated as automation contracts.

Operator priorities

The design is narrow on purpose.

SealPort is not trying to become a dashboard, daemon, scheduler, server, mount layer, or compatibility shim. The product center is encrypted backup and reliable restore from a local or S3-compatible repository.

Restore first

Backup features are judged by whether they make restore safer, clearer, and easier to verify.

Client-side encryption

Contents, names, directory shape, manifests, indexes, and sensitive config are designed to stay encrypted.

Evidence before claims

Platform support waits for CI, tests, release artifacts, and observed behavior.

Original repository format

SealPort does not read or write restic, rustic, Borg, Kopia, or rclone-native repositories.

Object-store discipline

Immutable objects, retry-safe writes, explicit commit markers, and no required rename assumptions.

Inspectability

Typed docs, structured events, and small crate boundaries keep behavior auditable as the system grows.

Design boundaries

The next work is the backup pipeline, then restore.

The current foundation is useful only if it leads to boring recovery. The public roadmap keeps that pressure visible.

  1. NowPhase 5 - backup pipeline

    source walking, exclusions, metadata capture, chunking, compression, encryption, manifests

  2. NextPhase 6 - restore pipeline

    snapshot selection, path-scoped restore, destination safety, metadata restore, verification

  3. ThenPhase 7+ - listing, check, retention, release

    snapshots, ls, find, diff, integrity checks, forget, prune, signing, SBOMs

Self-hosting shape

The website is separate marketing infrastructure.

This site is served by an Axum binary rendering Leptos views on the server. It has no database, no client-side app bundle, and a simple health endpoint for reverse proxies.

Binarysealport-webDefault bind0.0.0.0:8080OverrideSEALPORT_WEB_ADDR=127.0.0.1:8080