Blueprint

​

A Cloud Worth Building at Home

I want Technis to make running my own services as rewarding as using them. For friends and family, that means a welcoming place to watch something, find a favorite, request what is missing, and get help. For me, it means a place to design products, explore infrastructure, and turn what I learn into something useful to others. The ambition is a private family cloud with the care and coherence of a much larger platform. The audience stays small: my household and invited friends and family. The engineering can still be ambitious. Identity, deployments, observability, backups, recovery, and documentation are all opportunities to learn by building systems people actually use. There is room for play here, too. A homelab can be a miniature technology company, complete with its own Console, engineering stories, incident reviews, and a few automated coworkers. I want to enjoy that world without making family services depend on my latest experiment. Autonomy, privacy, and resistance to enshittification are the reasons to keep going. Replacing a subscription is satisfying; understanding the system, improving it, and being able to recover it are what make the replacement worth keeping.

​

Product Experiences

Planned: Video is the first complete Technis experience. Imagine accepting an invitation, connecting your account, finding something to watch, and starting playback without a setup conversation. If a title is missing, you can request it and follow its progress. If something breaks, you can report it and see whether it is already being investigated. Watchtower is my existing Plex client and the intended home for the custom browsing and playback experience. Shared navigation and direct links should connect it to the member portal. Each application should own a clear part of the journey so the same feature does not need to be maintained twice. Music comes later. Files, photos, documents, and household integrations can follow once the foundation is dependable. Nextcloud, Immich, and Paperless are examples of experiences worth exploring, not a promise that every integration is ready.

​

Membership and Identity

Planned: Membership remains invitation-only. An access request goes to me for approval; an invitation I initiate skips that step. After you create a Technis account, you connect Plex and receive the appropriate access. Onboarding should explain any unfinished steps instead of leaving you to guess which application needs attention. Technis will own the primary identity, with Plex and later services connected through supported authorization mechanisms. The goal is fewer repeated sign-ins without collecting your Plex password. Account linking, service provisioning, session handling, recovery, and revocation each need testing. Plex, Seerr, Tracearr, and Wizarr do not become interchangeable authentication systems simply because they know about the same person. Trusted media moderation does not grant infrastructure access or detailed viewing telemetry. Media restrictions remain separate from administrative roles. Household management is a later decision.

​

Requests and Discovery

Planned: Discovery will start with available content, recent additions, curated collections, and a clearly labeled way to explore titles that need requesting. Plex collections and playlists should remain easy to reach. A watchlist means “save for later.” Adding an unavailable title will not silently request it. Requesting is a separate action, and Plex watchlist synchronization remains an integration question.

• Member requests require approval from an administrator or trusted member.
• Administrator requests are automatically approved.
• Trusted members can approve any request, including their own; their submissions wait in the queue until explicitly approved.
• Quality uses a hidden default, initially proposed as 1080p. Trusted members and administrators can override it.
• Content will not be removed automatically. A media retention policy is a separate discussion.

Seerr is the intended foundation for requests and media issue reporting, with Wizarr evaluated for its place in onboarding. The Technis interface should make progress understandable without requiring you to learn those underlying tools.

​

Design Inspirations

Rasputin and Cloudflare are the dominant references. I want Technis to feel as coherent as those products while retaining its own identity. The useful question is what each interaction helps someone accomplish.

​

Rasputin: Make the System Tangible

Rasputin’s dashboard and task gallery makes a cluster feel like a place you can explore. Its node map leads to contextual controls, while the task view exposes the steps behind a change. Its architecture describes a central API and node agents. The Tasks source also supports links to a particular job or an application’s work. Planned: Carry that connection into Technis: select a resource, understand its state, inspect its dependencies, and follow an operation through to its outcome. A topology view could make the homelab fun to explore, alongside a searchable table for everyday work. The map should reveal relationships; its shape is a design choice. Rasputin remains an evolving project. Its custom operating system, app catalog, and update machinery are not Technis commitments. Adopting any component requires a separate fit assessment.

​

Cloudflare: Give Complexity a Readable Structure

Cloudflare’s documentation uses persistent product navigation, a readable central column, and a separate page outline. Search, breadcrumbs, and page actions keep a large collection navigable. Its sidebar source explicitly supports preserving navigation state. Planned: Use Cloudflare as the close layout and interaction reference for Technis docs and Console navigation, with Technis branding. Stable navigation, direct links, useful search, and consistent resource pages should make moving around feel predictable. Keyboard access, visible focus, readable contrast, and clear status labels belong in the design from the beginning. The visual direction combines Rasputin’s compact operational workspace with Cloudflare’s clear hierarchy: restrained panels, readable tables, contextual details, and room for the primary task. Technis’s blue and cyan accents establish its identity. Light and dark themes should both work well, and status must remain understandable without color alone. Dense operational views and comfortable reading pages can share a design language without sharing the same layout. The Cloudflare engineering blog is also a reference for giving technical work a public home. Technis articles should explain a real problem, show the design and evidence, and leave you with something you can apply to your own setup. Planned: Give the blog a similarly deliberate editorial layout: a featured story, clear dates and authorship, concise summaries, topic browsing, and generous space for diagrams and technical explanations inside articles. The public front page should introduce what members can use and lead clearly to access, documentation, and status.

​

Specialist Tools: Borrow the Useful Details

These are references, not a shopping list or a commitment to embed every product. The Kubernetes project now describes its old Dashboard as deprecated and unmaintained, and points new installations toward Headlamp. Dockhand’s source is available for study, but reuse and required permissions need their own licensing and edition assessment.

​

Admin Console

Planned: The Console is the place I want to open when I ask, “What is happening across Technis, and what needs me?” It should connect service health to the infrastructure, deployments, backups, and workers behind it. The opening view will prioritize active incidents, unhealthy resources, failed deployments, overdue backups, pending approvals, and capacity risks. It should also make a healthy estate pleasant to browse. Services and infrastructure offer two routes into the same resources: start with Video and follow its dependencies, or start with a host and see what depends on it.

​

From a Symptom to an Answer

Consider a failed playback session. The Console should help trace whether the failure lies with the service, a container, its host, or storage. Relevant metrics, logs, recent changes, and runbooks belong within reach. Telemetry needs timestamps and explicit unknown or disconnected states. An authorized action should then become a visible job with a target, actor, progress, and result. Links from incidents and resource pages should open the relevant job directly. Inspecting an old job must not repeat the operation. Human actions and worker actions should be equally accountable. Planned: Begin with visibility, history, and a few complete operational workflows. Link to specialist tools where they already solve deeper problems well. Add native Console controls when they remove recurring friction. Evaluate existing APIs and agents before selecting a custom agent or transport.

​

Git Defines the Services

Services enter Technis through repositories, infrastructure as code, and deployment automation. The Console will display those services and their deployments. It will not offer an application marketplace or an independent “add service” path. Runtime actions and configuration changes have different meanings:

• Restarting an existing container does not require a Git change or pull a new image.
• Pulling an image and recreating a container are separate actions. A mutable tag can change the deployed image without changing the repository.
• Deployment history should record the actual image digest and the previous version needed for recovery.
• Configuration changes follow the repository workflow. Emergency overrides must be visible and reconciled afterward.
• Destructive actions require confirmation; routine permitted actions should stay straightforward.

​

A Shell Within Reach

Planned: Provide a persistent personal workspace with administrative tools and repository access, plus separate terminals attached to a selected host, container, or Kubernetes workload. The target and environment must stay obvious, especially in production. Administrative controls and shell access remain private and strongly authenticated. The Console is an operating tool, not a dependency for every service. Monitoring, backups, and workloads should continue if it is unavailable, with independent administrative access and recovery instructions.

​

Documentation and Publishing

This public documentation site now uses Mintlify. The immediate task is to improve the current site and determine how the desired private documentation can be delivered safely. Planned: Public pages explain products, general architecture, and design decisions. Authenticated member pages cover relevant service instructions. Administrator-only pages contain sensitive operational detail and recovery procedures. The current repository is public. Private material must live in private source and protected delivery, with authorization covering pages, search, assets, and previews. Hiding a sidebar item cannot protect content already shipped in a public build. The exact arrangement remains open; no private-docs capability is claimed here. Emergency recovery instructions also need an independently available local copy. I want the docs to grow with the work: guides for using a service, explanations of design choices, and engineering articles about what actually happened. A restore exercise, a difficult performance problem, or a failed experiment can all make a useful article. Automated workers may gather evidence and draft material, but I retain editorial responsibility and approve publication.

​

Reliability and Data Protection

Planned: Build on existing hardware, using Compose and Kubernetes where each fits. Keep experiments separate from the services people rely on, including their credentials and production access. Before an experiment becomes a supported service, it needs a usable onboarding path, monitoring, backups where appropriate, and a tested recovery procedure.

​

Initial Recovery Targets

These are engineering goals to validate through exercises. They are not availability guarantees or claims that failover already works.

​

Recovery Is Part of the Product

Planned: Apply a 3-2-1 data strategy with local copies and a future off-site TrueNAS system. Protect irreplaceable data, configuration, and replaceable media according to their different recovery needs. Prove copy independence, retention, key recovery, and restoration; snapshots alone do not establish the whole strategy. Full off-site media coverage remains a capacity decision. Backups will use equipment I control, not cloud backup storage. Cloudflare usage stays within free tiers, and new spending, including AI usage, requires deliberate approval. Local Technis access should survive a Cloudflare outage. That requires testing local name resolution, routing, authentication, and application dependencies together. Direct access to Plex is one part of that exercise, not proof of the whole platform’s independence. Test updates before promotion. Low-risk changes may deploy within maintenance windows; migrations and changes to authentication, storage, or networking initially require approval. Reverting an image does not reverse every database change. During time away, keep proven recovery and backups running while deferring changes with uncertain recovery. Document an emergency handoff for a trusted operator. Recovery exercises should become useful engineering projects in their own right: restore into a clean environment, measure how long it takes, and document what made the process easier the next time.

​

Observability and Accountability

Planned: Monitor what members experience alongside what machines report. Successful sign-in, playback, requests, and fulfillment matter just as much as process uptime. Infrastructure coverage includes disks, filesystems, containers, jobs, hosts, storage, networking, and backups. Alerts should reflect consequences. Imminent data loss, missed backup recovery objectives, and security incidents deserve urgent attention. A streaming outage needs a clear operational notification. A safely recovered process restart may only need an event record. Related failures should form one incident rather than a flood of unrelated alerts. The website will be the authoritative status record. Discord can deliver notifications and commands without becoming mandatory for understanding an outage or getting help. Transparency should explain failures and improvements without exposing viewing activity, credentials, or sensitive infrastructure details. Reliability objectives will follow meaningful user journeys, drawing on Google’s SRE guidance.

​

Device Inventory and Household Scope

Planned: Extend the Console’s understanding beyond servers to the technology around the home: computers, phones, televisions, networking equipment, and smart-home devices. Discovery can help identify what is present, where it belongs, and which services it depends on. This is inventory, not personal-device management. Technis will not install software, enforce settings, control personal devices remotely, or manage their updates. Infrastructure administration remains a separate responsibility. New observations enter an unidentified-device queue for review. Private inventory may contain network addresses and useful ownership or lifecycle metadata, but these do not belong in public documentation. Changing addresses must not be mistaken for permanent identity. New integrations are opt-in. Household controls should keep working independently of the Console. Future smart-home integrations can make the home easier to understand and maintain without requiring a dashboard just to turn on a light.

​

Workers and Company Operations

Planned: Explore automated coworkers with concrete responsibilities and visible results. The interesting experiment is whether a small team can reduce repetitive work while leaving me more time for design and infrastructure engineering. Each worker needs a task queue, limited permissions, and a record of its actions. Authority expands through demonstrated reliability. Product decisions and publication approval remain mine. Paperclip is a candidate for organizing that work, not a selected dependency. Named responsibilities and a weekly operational brief are a useful starting point. The company simulation can grow where it makes the work more understandable or more fun; it does not need a department for every script.

​

Delivery Sequence and Acceptance

Planned: Build in stages that each leave something useful behind. The first foundation is ready for a 30-day operational trial when an invited member can onboard and watch without help, a request reaches the library, an issue reaches the operator, and access can be revoked. A failed update must recover safely, protected data must restore into a clean environment, and an outage must produce accurate public status. Documentation privacy, role boundaries, and local continuity also need explicit tests.

​

Evidence and Open Questions

This draft was reviewed against public reference sites, official documentation, selected UI source files, and the local docs configuration on September 25, 2026. Rasputin’s published dashboard imagery, Cloudflare’s docs layouts, and Dockhand’s gallery informed the design discussion. These observations are not runtime tests of those products or of Technis. The next investigations are concrete:

• Verify the live inventory and whether the existing hardware can meet the proposed recovery targets.
• Test Watchtower and the identity, request, and onboarding integrations as one journey.
• Choose identity and secret-management approaches that preserve a local recovery path.
• Determine protected documentation hosting and search boundaries within the spending constraints.
• Test backup independence, retention, and off-site restore feasibility.
• Evaluate telemetry, agent connections, and worker coordination against existing tools before building replacements.

The payoff is a platform that gives members useful services and gives me better experiments to run. Movie night, a successful recovery drill, an informative incident review, and an engineering article should all be things Technis makes easier.