case study / infrastructure
activePortable Bridge Workspace
A removable workbench with repo hub, provider API access, Git pushes, and private VPS-backed development.
- Linux
- Git
- SSH
- Forgejo
- Shell scripting
This project is a portable development control plane built around a removable drive, a private VPS, and a self-hosted Git service with private-by-default, selectively public repositories.
The goal is practical: make the drive useful to any trusted workstation or coding agent without turning chat history, a single laptop, or a public code host into the source of truth.
What it is
A bridge workspace for project work:
- project working copies live on the removable drive
- private Git history lives on a VPS-backed forge
- public releases can still be pushed to a public code host when a repo is meant to be shared
- repo-hub provides the shared menu for status, Git pushes, and handoff decisions
- helper scripts make SSH and Git consistent across machines
- provider API credentials can travel with the drive for DNS and recovery automation
- documentation travels with the drive so the workflow can be resumed later
Why it exists
The system separates three jobs that are often mixed together:
- The removable drive is the portable workbench.
- The VPS is the durable home base and canonical Forgejo source.
- Public Forgejo visibility and external mirrors are enabled only for intentionally published work.
That split keeps private infrastructure private while still allowing selected projects to be published publicly.
What it does
- carries enough context for another trusted environment to understand the project layout
- keeps project sync centered on Git instead of ad hoc file copying
- supports private-only pushes to the VPS
- supports dual-push for repos that should exist privately and publicly
- can update DNS through provider APIs when manual control panels get in the way
- exposes repo-hub as the main menu for checking status, pulling, pushing, and commit-push workflows
Repo hub
The key interface is a terminal menu that lists every project repo, shows dirty state and upstream sync, and makes push decisions explicit.
It gives a coding agent or trusted workstation one obvious first command: inspect the repo hub before deciding what to touch.
Provider API layer
The bridge can also carry provider API access for controlled infrastructure work.
The immediate use case is DNS: moving records, removing stale web-hosting targets, and confirming that the public domain points at the VPS. A separate server-control API can be added later for snapshots, power actions, inventory, or emergency recovery.
That API layer does not replace SSH or Git. It is a narrow provider-control layer around the private VPS workflow.
What is intentionally omitted
- server addresses
- domains
- usernames
- SSH keys, fingerprints, and secret paths
- API keys, token formats, and provider account identifiers
- provider account details
- recovery credentials
- exact local mount paths
Technical themes
- portable workspaces
- private Git hosting
- SSH trust boundaries
- self-hosted development infrastructure
- repo mirroring and dual-push
- documentation as operational memory