Where is up to.

is one server for your mail, files, calendars and AI, on hardware you own. This is every part of it, in four stages, ticked off as each piece ships. There are no dates: a stage is finished when its work runs well on real hardware, not when a calendar says so.

Release 0.20.1 · Updated 24 October 2026

Foundation
The groundwork the other parts stand on. Most of it you never see.
34 of 46 done
First release
What has to be in place for the public launch.
52 of 55 done
Next
The first round of improvements once people use it every day.
4 of 45 done
Later
Worth doing, once the rest is solid.
0 of 28 done

Every part, stage by stage

Open a part to see its checklist. 90 of 174 items are done.

Desktop and phone

One web app with two shells: windows, a dock and a menu bar on a big screen, and full-screen apps with a bottom bar and a Jethro sheet on a phone. The shell is picked by screen size and touch, not by device, so a tablet can use either. Every app is written once and declares how it lays out in both.10 of 14 done

Foundation 4 of 4 done

Done: Design tokens, fonts and icons packaged as one shared UI kit
Done: Shell framework that switches between desktop and phone layouts
Done: Window manager: open, move, resize, snap, minimise, focus
Done: App frame that loads an app in a sandbox and passes it the layout it is in

First release 5 of 5 done

Done: Desktop: dock, menu bar, server widget, wallpaper, light and dark
Done: Phone: bottom bar with five pinned apps, More drawer, Jethro sheet, 44 px touch targets
Done: Installable on a phone home screen
Done: Keyboard shortcuts and screen reader labels on every shell control
Done: Desktop app for Windows, macOS and Linux

Next 1 of 3 done

Not started yet: Tablet layout: split view of two apps
Not started yet: Gestures: swipe between apps, pull down for notifications
Done: Per-person layout sync, so a dock set up on one device follows you

Later 0 of 2 done

Not started yet: Native phone wrappers for iOS and Android, if the web app falls short on push or files
Not started yet: TV or kiosk layout for a shared screen in the house

People and permissions

Everything is private to its owner until shared, and every request, from a person, an app or Jethro, goes through one permission check. People are sorted into groups, and groups own shared spaces.9 of 14 done

Foundation 4 of 4 done

Done: Accounts, groups and roles in the core database
Done: One policy check that every API call passes through, with tests for each role
Done: Scoped tokens for people, apps and Jethro
Done: Audit log

First release 4 of 4 done

Done: Owner created at setup; invite people by link or email
Done: Owner, Admin, Member and Child roles, with parent controls; Everyone group
Done: Share files and folders with a person or group
Done: App grants shown and approved at install, revocable in Settings

Next 1 of 4 done

Done: Guest role and guest expiry
Not started yet: Custom groups and group-owned Spaces
Not started yet: Public share links with password and expiry
Not started yet: Manage level and ownership transfer

Later 0 of 2 done

Not started yet: Several separate households or teams on one server
Not started yet: Per-app admin delegationFor example, someone who manages only Photos

Sign-in

is its own sign-in provider, so one account works across the desktop, every app and every service behind your domain. Signing in with Google, GitHub or another provider is an option a person can link, never a requirement.8 of 13 done

Foundation 3 of 3 done

Done: Password sign-in with secure hashing, sessions and sign-out everywhere
Done: OpenID Connect provider in the core
Done: A sign-in check the router runs on every request

First release 5 of 5 done

Done: Passkeys and authenticator-app two-factor; admins can require two-factor
Done: Sign-in pages in the Solel style, on the desktop and phone
Done: Register an external app as an OIDC client from Settings
Done: API keys with grants and expiry
Done: Session list: see and end sessions on other devices

Next 0 of 3 done

Not started yet: Link Google, GitHub, Microsoft or Apple as a way to sign in
Not started yet: Device sign-in for the desktop app and TVsShow a code, approve on the phone
Not started yet: Sign-in alerts for a new device

Later 0 of 2 done

Not started yet: LDAP for older apps that only speak that
Not started yet: Sign in to one Solel server with an account from anotherFriends and family across houses

Domains and remote access

offers three ways in, picked at setup and changeable later: a direct connection, a relay for networks that can't open ports, and a private tunnel for your own devices. Any of them works with your own domain, and every app can have its own subdomain.9 of 15 done

Foundation 4 of 4 done

Done: Embed Caddy in the core; routes stored in the database, not a text file
Done: Validate-then-apply for every change, with automatic roll back
Done: DNS pre-check before every certificate request
Done: Every app behind the router signs in with Solel

First release 4 of 5 done

Not started yet: Direct mode with an outside port test
Done: Bring your own domain, manual and Cloudflare automatic
Done: Per-app subdomains, custom routes, sign-in setting and upload limit per route
Done: Certificate status page with Retry now
Done: Private WireGuard access with QR setup

Next 1 of 4 done

Not started yet: Solel relay for networks that can't open ports
Not started yet: Free Solel subdomain
Not started yet: More DNS providers for automatic mode
Done: Detect a changed IP address and update DNS

Later 0 of 2 done

Not started yet: Choice of relay region, and running your own relay
Not started yet: Peer-to-peer connections between Solel servers

Updates

We publish each release from GitHub Actions, and every server picks it up from a signed feed, snapshots itself, updates, checks its own health and rolls back by itself if anything fails. Owners choose when updates install, and security fixes can be set to install straight away.7 of 12 done

Foundation 4 of 4 done

Done: Release pipeline in GitHub Actions: build, sign, publish to the feed
Done: Signed feed format and the key ceremony for the offline signing key
Done: Updater in the core: check, download, verify, apply
Done: Health check after an update, with automatic roll back

First release 3 of 3 done

Done: Stable and Beta channels
Done: Settings page: what's new, install now, schedule overnight, auto-install security fixes
Done: Desktop app updates itself through a signed updater

Next 0 of 3 done

Not started yet: Staged rollout with pause and pull
Not started yet: Opt-in anonymous update health reports
Not started yet: Separate update tracks for apps and models

Later 0 of 2 done

Not started yet: Whole-system image updates (A/B partitions) for the installable OS image
Not started yet: Delta downloads to cut update size

Snapshots and backups

Snapshots stay small because they store only what changed since they were taken, and the update snapshot covers just the system, settings and databases, not people's files or model weights. A fresh snapshot costs next to nothing; it grows only as the live data drifts from it, and old ones are pruned automatically under a size cap you can see.5 of 11 done

Foundation 2 of 3 done

Not started yet: Install onto btrfs by default; detect the filesystem on existing installs
Done: Snapshot and restore API in the core, with the size cap and pruning
Done: Fallback deduplicated store for non-btrfs disks

First release 3 of 3 done

Done: Automatic snapshot before every update, used for roll back
Done: Snapshots page with space used, restore and delete
Done: Scheduled backup to a second disk or USB drive, with a test restore

Next 0 of 3 done

Not started yet: Hourly or daily file snapshots, so a person can bring back yesterday's version of a file themselves
Not started yet: Encrypted offsite backup to S3-compatible storage
Not started yet: Backup to a friend's Solel server, each holding the other's encrypted copy

Later 0 of 2 done

Not started yet: ZFS support for people who already run it
Not started yet: Whole-server restore onto new hardware from a backupTies into Recovery

Apps and the App Store

Every app, built-in or from the store, is the same kind of thing: a front end in a sandboxed frame, an optional back end in its own container, and a manifest listing the grants it needs. The built-in apps are written on first, which proves the SDK before anyone else uses it.8 of 14 done

Foundation 4 of 4 done

Done: App manifest format: name, icon, version, grants, layouts, back end, health check, subdomain
Done: App manager in the core: install, start, stop, update, remove, with each app's data kept apart
Done: (TypeScript, Apache-2.0): windows, files, notifications, permissions, calling Jethro
Done: Container runtime for app back ends, limited to declared grants

First release 4 of 4 done

Done: Built-in apps: Files, Mail, Calendar, Contacts, Photos, Jethro, Settings
Done: Install from a manifest URL or a local file
Done: Per-app health check and restart
Done: Remove an app and choose whether to keep its data

Next 0 of 4 done

Not started yet: App Store: a signed catalogue, listings with screenshots and the grants in plain words
Not started yet: Developer docs, a starter template and a local test harness
Not started yet: Review process for store submissionsAutomated checks plus a human look
Not started yet: Popular self-hosted apps packaged for one-click installFor example Jellyfin, Home Assistant, Immich

Later 0 of 2 done

Not started yet: Paid apps in the App Store
Not started yet: Third-party store catalogues an owner can add

AI models and Jethro

Models run in one inference service on llama.cpp, which covers AMD, NVIDIA and plain CPU. A GPU scheduler decides what is loaded, so a chat model and image generation can share one graphics card without overfilling it. Jethro and every Sol run on the Genesis Engine, Solel's agent harness, and act only through the person's own permissions.7 of 17 done

Foundation 2 of 4 done

Done: Inference service with an OpenAI-compatible API; builds for ROCm, Vulkan, CUDA and CPU
Not started yet: Hardware detection: card, driver, memory
Not started yet: GPU scheduler with load, unload, queue and priorities
Done: Genesis Engine wired to the inference service, with its tools calling the Solel API under the person's own sign-in

First release 4 of 4 done

Done: Angel, Dominion and Seraphim as GGUF builds, with a pick based on the detected hardware
Done: Models page: download, switch, remove, see memory use
Done: Jethro on desktop and phone: chat, voice, drafts in Mail, files search, calendar
Done: Jethro confirms before sending, deleting, sharing or spending

Next 1 of 4 done

Not started yet: Image generation as a scheduled GPU job
Not started yet: Two-card support (for example a Radeon and an NVIDIA in one box), each model pinned to a card
Not started yet: Sols with their own personalities and faces42 ready-made Sols, sharing, group chats and a face picker are in; the face studio is left
Done: Apps can ask Jethro for help through the SDK, with the person’s permission

Later 0 of 5 done

Not started yet: vLLM for large NVIDIA cards
Not started yet: Fine-tuning or personal adapters trained on your own server, overnight
Not started yet: Parity list: every harness feature Solel uses, with tests that both harnesses must pass
Not started yet: Solel's own harness, built against those tests, then swapped in
Not started yet: Remove the original harness code and its About credit once nothing depends on it

Storage and health

The owner can see every disk, what fills it and whether it is healthy, add a disk without a terminal, and gets warned before a disk fails rather than after. Each person can also see their own usage, and the owner can set quotas.4 of 12 done

Foundation 1 of 3 done

Done: Disk discovery and SMART health readings
Not started yet: Storage pools on btrfs: one disk, or two mirrored
Not started yet: Usage by person, app, models, snapshots and backups

First release 3 of 4 done

Done: Storage page: disks, space by category, health status in plain words
Done: Warnings at 80% and 95% full, and on any SMART failure sign
Not started yet: Add a second disk as a mirror or as backup space
Done: Clean-up suggestions: unused models, old snapshots, trash

Next 0 of 3 done

Not started yet: Per-person quotas
Not started yet: Replace a failing disk with a guided swap
Not started yet: Monthly scrub to catch silent corruption, with a report

Later 0 of 2 done

Not started yet: Pools of mixed-size disks
Not started yet: Network storage (a NAS share) as extra space

Notifications

One notification centre that apps, Jethro and the server all post to, delivered to the desktop, to phones as push, and by email for server alerts. Push goes from your server to the phone without a Solel cloud service reading it.7 of 11 done

Foundation 3 of 3 done

Done: Notification API in the core and the SDK, gated by a notify grant
Done: Web Push from the server, with keys generated at setup
Done: Outgoing email for alerts, through the built-in mail server or an SMTP relay

First release 4 of 4 done

Done: Notification centre on desktop and phone, with read and clear
Done: Phone push for the installed web app
Done: Per-app on and off, and quiet hours
Done: Server alerts (disk, backup failed, update ready, certificate problem) to admins by push and email

Next 0 of 3 done

Not started yet: Jethro summaries: one morning digest instead of many pings
Not started yet: Actions on a notificationReply, snooze, approve
Not started yet: Ntfy or Gotify for people who want an existing push app

Later 0 of 1 done

Not started yet: Native push through Apple and Google if native phone apps happen

Monitoring and logs

Every app and service has a health check, the owner sees one status page that says in plain words what is wrong and what to do, and logs are kept on the server for when something breaks. Nothing is sent anywhere unless the owner turns on crash reports.5 of 11 done

Foundation 1 of 3 done

Done: Health check contract in the app manifest, polled by the core
Not started yet: Structured logs from the core and every app, kept for 14 days by default with a size cap
Not started yet: Metrics: CPU, memory, GPU, disk, network, per app

First release 4 of 4 done

Done: Status page: each app and service green, amber or red, with the reason and a fix button where there is one
Done: Server widget on the desktop with the headline numbers
Done: Automatic restart of a failed app, with a limit so it doesn't loop
Done: Log viewer for admins, filtered by app

Next 0 of 3 done

Not started yet: Download a support bundle (logs and settings with secrets removed) to send to Solel support or a forum
Not started yet: History graphs for the last week
Not started yet: Jethro can read the status page and explain a problem

Later 0 of 1 done

Not started yet: Prometheus endpoint for people who run their own monitoring

Recovery

The owner can get back in after losing a password, and the server can be reinstalled or moved to new hardware without losing anyone's data. Recovery always needs physical access or a recovery code, so it can't be used to break in from outside.5 of 9 done

Foundation 1 of 2 done

Done: Recovery codes generated at setup, shown once, with a prompt to print or save them
Not started yet: People's data and the system kept on separate volumes, so a reinstall leaves data untouched

First release 4 of 4 done

Done: Forgotten owner password: reset with a recovery code, or from the machine's own screen or a USB key
Done: Forgotten member password: an admin sends a reset link
Done: Safe mode: boots the core with apps off, to undo a bad change
Done: Reinstall that finds the existing data and picks it back up

Next 0 of 2 done

Not started yet: Restore a whole server onto new hardware from a backup
Not started yet: Account recovery through a trusted second person

Later 0 of 1 done

Not started yet: Recovery USB image that boots, checks disks and restores

Moving in

Moving in is a guided import, offered at the end of setup and from Settings, that brings a person's photos, mail, files, calendar and contacts from Google, Apple or Microsoft into the matching Solel apps, then helps them stop paying for the old storage. It runs in the background on the server, survives restarts, and never deletes anything at the source.3 of 12 done

Foundation 0 of 3 done

Not started yet: Import job runner: resumable, throttled, reports progress through notifications
Not started yet: Content-based duplicate detection shared by Photos and Files
Not started yet: Read-only OAuth connections for Google and MicrosoftNeeds app registration with each

First release 3 of 3 done

Done: Google Takeout import for Photos, Mail, Drive, Calendar and Contacts
Done: Moving-in wizard at the end of setup and in Settings
Done: Summary page with what was skipped and why

Next 0 of 4 done

Not started yet: Direct pull from Google and Microsoft accounts instead of an export file
Not started yet: Apple iCloud import from an export
Not started yet: Ongoing mail sync from the old account until switched over
Not started yet: Tidy-up checklist for forwarding and cancelling storage

Later 0 of 2 done

Not started yet: Import from Dropbox, Facebook and Instagram exports
Not started yet: Move from one Solel server to another

Privacy

Nothing leaves the server unless a person turns it on, and every setting that sends data out says exactly what goes where. The only outbound traffic by default is checking the signed update feed, which sends no personal data, and certificate requests for domains the owner set up.3 of 9 done

Foundation 1 of 2 done

Done: Outbound network grant in the permission system, so no app reaches the internet without network.internet
Not started yet: Encryption of secrets at rest; full-disk encryption offered at install

First release 2 of 3 done

Done: Privacy page listing every outbound connection the server makes, live
Done: Defaults above, set at install, shown in a plain-words summary at the end of setup
Not started yet: Privacy policy for solel.io and the update feed

Next 0 of 2 done

Not started yet: Per-app outbound log a person can read
Not started yet: Export all my data, and delete my account and data

Later 0 of 2 done

Not started yet: Independent security review
Not started yet: Australian Privacy Principles check

Something missing?

Tell us what you need to do, and we'll add it to the right stage. Write to hello@solel.io.