deputyOS year-one roadmap: where we're heading

The full milestone-by-milestone roadmap lives in the repo. This post is the user-facing version: where we’re heading in the next ~12 months, and why each thing matters.

The shape of year one

deputyOS today (v0.3.0) is what you’d call a public preview: the appliance works on 14 hardware targets, three profiles ship (OpenClaw, Hermes, Khoj), the security baseline is solid, the wizard is polished, the air-gapped tier works, and the drive-mounting subsystem is in place. The big open work is at the infrastructure layer — public CDN, signed-release pipeline running on real hardware, audit, marketplace listings, and the desktop launcher notarized so non-technical users can double-click.

Roughly in priority order:

Now → +6 weeks (M4a, M4b)

Stand up the public CDN and signed-release pipeline.

cdn.deputyos.com (Cloudflare R2 backed) live with signed manifests per channel.
First public tag (v0.3.0) cut on GitHub; signed artefacts mirrored to the CDN.
The picker on the homepage resolves real download URLs.
The release workflow on GitHub Actions runs end-to-end (build → smoke → sign → manifest → R2 push).

When this lands, the steady-state release loop is:

Upstream profile releases a new version.
The release-tracker bot opens an auto-PR.
CI builds the new image across the matrix.
Signed manifest publishes.
Devices in the field pull and apply.

That loop has been tested locally; the missing piece is the public infrastructure.

+1 → +3 months

Marketplace listings + cost guardrails polish + audit procurement.

DigitalOcean 1-Click Marketplace listing approved (was deferred on submission).
Cost guardrail “spending paused” banner in the PWA polished; one-tap raise-cap action.
External security audit vendor selected; threat model externally reviewed.

The audit is the biggest of these. Self-attestation only goes so far for an appliance shipping in the field. Getting an outside firm to walk the threat model — secrets storage, AppArmor profiles, update trust chain, channel auth — is something users can lean on. The report will be public.

+3 → +6 months

Egress whitelist mode + voice polish + A/B rollback on real hardware.

The network-policy schema extends with mode=whitelist and an allow_hosts: [...] array. nftables generator lights up the path. Wizard offers three egress modes (open / whitelist / airgap). This is the middle ground for users who want “open internet, but only to api.openai.com and Telegram.” See signing-and-trust-chain for context on the policy file shape.
Voice wake-word + Piper TTS on rpi5 polish. Should round-trip in under 2 seconds on rpi5 8 GB. Custom wake-words.
A/B image swap verified on a Pi 5 with a deliberately broken update — must auto-rollback within 5 minutes. Currently smoke-tested on qemu only.

The egress-whitelist mode is the feature we hear most-requested. Users want the privacy of air-gapped without losing access to the model providers they pay for. The schema is already designed to be forward-compatible; the implementation is not yet shipped.

+6 → +9 months

Third-party SLSA verification + desktop launcher notarization.

A second independent build host runs the same workflow; the verifier compares byte-for-byte. SLSA L3 reproducible-build attestation is the result. (Today we generate the attestations; what’s missing is the second host that re-attests.)
Desktop launcher polish: Apple Developer ID + macOS notarization complete. Windows EV cert in place. Non-technical Win/Mac users can double-click without OS warnings.

The desktop launcher is the path to mainstream adoption. WSL2/UTM/qemu work today for technical users; SmartScreen + Gatekeeper warnings turn off non-technical users. Apple notarization is procurement work, not engineering work — it’s just a slog.

+9 → +12 months — the commercial layer

Opt-in cloud accounts + managed backup/restore.

This is the business model.

Free tier: 1 device, 1 GB encrypted backup, 30-day retention.
Paid tiers: more devices, more storage, longer retention. Pricing TBD.
Local-first invariant preserved: every flow works without an account. The account purely adds restore-on-new-device.

The shape: client-side age-encrypted bundles pushed to a per-user Cloudflare R2 prefix. The server stores opaque ciphertext only; it cannot read your data. You can flash a new SD card, deputyctl login, deputyctl restore --from cloud, and your device is back to where you left off.

Why this is the business model: we don’t want to monetize the agent (would create perverse incentives) or telemetry (against the privacy posture). We do want a way for the project to fund itself sustainably. Selling encrypted backups is the cleanest path: it’s a real service users actively want, it doesn’t touch your data semantically, and it doesn’t change deputyOS’s fundamental shape.

We’ll publish the threat model for the accounts layer before any code lands. An external audit is part of procurement readiness.

Year-end: where v1.0 lands

If everything above goes well, v1.0 is:

Public CDN live, signed releases, A/B updates verified on hardware, audit report published.
DO Marketplace listing live; desktop launcher works smoothly on Win/Mac/Linux.
Three egress modes (open / whitelist / airgap); wizard surfaces all three.
Three profiles shipped (and probably a fourth, see below).
Optional cloud-backup tier available.
Voice + drive-mounting polished.

That’s the appliance we’d be comfortable telling a non-technical friend to install.

Fourth profile (probably this year)

Likely candidates we’ve considered:

A coding-specialist profile — multi-channel like OpenClaw but routes coding tasks to specialised tooling. Lots of demand.
A note-taking-focused profile — lighter than Khoj; more like “Obsidian + an agent” than full personal-search.
A research-assistant profile — RAG-heavy, paper-ingestion, citation-aware. Closer to Hermes’ shape but specialised.

We won’t add a profile just because it’s a category; it has to be a real personal AI assistant. The bar is high deliberately — we want the catalog to stay small and curated.

If you have a candidate, the add-a-profile doc is your starting point. Manifest + Ansible bake recipe + AppArmor profile + systemd unit. Zero Rust changes needed.

Things we won’t do this year (and why)

A vendor LLM. We don’t want to compete with OpenAI/Anthropic; we want to integrate with whichever the user picks.
Telemetry on by default. Opt-in OpenTelemetry is on the roadmap, but never on by default.
A SaaS dashboard for “managed deputyOS fleets.” We’ve been asked. It’s not us. There may be a third party who builds it; we’d be supportive.
A custom kernel. Debian’s stock kernel is enough. Custom kernels are a maintenance burden we won’t take on.
WhatsApp Business API in the box. Meta verification is annoying enough that users need to do it themselves; we document the path.

Things we’re hoping for

An external contributor base. The plugin model (no Rust changes for a new profile) is designed for this. Khoj as the third profile proved it works. We want more.
Hardware partners. A pre-flashed Pi 5 + case + PSU + NVMe SSD that lands at someone’s door, ready to plug in. If you make one and want to talk, we’d love to.
Self-host communities. This whole project rhymes with the broader self-hosted movement (Home Assistant, Nextcloud, Plex’s local mode). We learn from those projects constantly and would like to be useful to people in those communities.

The TL;DR for the next 12 months

Less new shiny; more polish, more hardware coverage, more verification, more user surfaces. The next thing we ship that you can hold is v1.0, and the year between now and then is spent making it stable enough that a non-technical user is happy with it on day 30, not just day 1.

You can follow along on the GitHub roadmap, watch deputyos/deputyos for releases, or just check back here — the next milestone post is in flight.

If you’re in already: thank you for the early-adopter patience. If you’re not yet: the picker and the 10-minute Pi 5 walkthrough are how you get started today.