Features in Detail
Broken down by the three roles: wearer, keyholder and operation.
Wearer — record & review
The wearer documents every phase of chastity, manages their own devices and keeps statistics, goals and status in view.
Time Tracking & Live Status
Locking, unlocking, inspection and orgasm are captured as events with photo, note and assigned device. The live status shows whether currently locked and runs an ongoing timer for the wear time. This builds a complete chronicle of every lock-up.
Device Management
Each chastity device is created with a photo and purchase price. From the recorded wear time the application calculates the total duration per device and the cost per wear-hour. Multiple devices can be kept side by side and compared.
Cleaning Openings
Cleaning breaks are recorded as separate openings and subtracted from the running wear duration. A lock stays active while the break time is correctly excluded. During a break the dashboard shows the remaining time and a button to lock up again; the permitted times of day are set by the keyholder. With automatic inspections switched on, the re-lock is followed by an inspection of its own accord.
Tasks — Conditions Held to a Deadline
A task is more than a checkbox: it requires conditions — wearing certain devices, staying locked — up to a deadline, and where the keyholder sets it that way they must hold continuously rather than just be shown once. The task card on the dashboard shows what is still missing and what to do next. A separate "Time to get ready" names the point by which you must have started; miss it and the task counts as missed. Completed, missed and withdrawn tasks stay readable in the list below the card.
Key Proof Through the Viewing Window
Anyone using the Heimdall key safe can take a photo through its viewing window when locking up and at every inspection. Image recognition checks whether a key is visible in it at all — it cannot tell which one, and it blocks nothing; it is a signal for the keyholder, not a proof. If the box has reported itself locked continuously since the lock-up or the last photo, and the bolt has not moved in between, the key still counts as being inside at the next inspection — and the keyholder can see what the evidence rests on: photo or box report. If any of that is missing, only a photo counts again.
Multi-Category Tracking
Beyond the classic cage, categories such as plug, collar or cuffs can be tracked separately. Each category keeps its own entries, goals and calendar. This keeps parallel wear dynamics cleanly separated.
Personal Statistics
A calendar heatmap, a monthly overview and goal progress summarise the recorded data. Trends across longer periods become visible at a glance. The analysis covers all categories and devices. Day, week, month and year boundaries are calculated in the wearer's own time zone rather than Swiss time, so the analysis is correct outside Switzerland as well.
Orgasm Tracking
Orgasms are recorded as separate events with time, type and an optional note. Combined with the keyholder's requirements, this builds a complete picture of permissions and instructions. The history is available at any time.
Code Vault
The photo of a sealed key safe or code note is stored locked and stays hidden. Only after release by the keyholder can the image be viewed. This stores an emergency key code without it being visible ahead of time.
Notifications
Push and email notifications report due inspections, deadlines and directives. This ensures the keyholder's requirements are not missed. Delivery runs as web push in the installed PWA; on iPhone and iPad this requires the site to be on the home screen.
Inbox — Read Keyholder Messages
The bell in the app header opens the inbox and carries the number of unread messages, shown as "99+" from a hundred onwards; the same counter appears as a badge on the app icon. Penalty texts with their reasoning, inspection comments, messages about requirements and lock periods, reminders and automatic entries all stay readable there for good. Push and email only deliver — the inbox keeps, even when a mail goes unnoticed. The penalty text was the clearest case: only the keyholder sees the penalty log, so anyone who missed the mail never learned what they were penalized for. The dashboard banners still answer what needs doing now; the inbox answers what was said — deliberately without a countdown and without urgency.
Passkey Login
Sign-in is possible via passkey without a password. Access uses device biometrics or a security key. This simplifies login and increases account security.
Apps & Offline-First
The application is an installable PWA: it is added to the home screen straight from the browser and then runs full screen, with no app store and no approval from Apple or Google. Recorded data is available offline-first and syncs once a connection is restored, so recording works reliably on the go. Native apps exist on top of that: the iOS version is in development and handed out as a TestFlight beta, and for Android there is an APK file — both on request.
Keyholder — direct & control
The keyholder sets lock periods, requests inspections, defines goals and keeps the penalty log — manually or assisted by an AI keyholder.
Pure Keyholder Role: No Own Tracker
A keyholder does not have to track themselves. The "No own tracker" mode hides your own tracker area and sends the login straight to the keyholder overview. No data is deleted, and the switch can be reversed at any time. This keeps the role honestly separate: control without wearing a device yourself.
Inspection Requests
The keyholder requests an inspection with a code and a deadline, which the wearer confirms by photo; the deadline defaults to one hour and can be given in minutes. Inspections cover the chastity device as well as wear categories such as plug, collar or cuffs — optionally targeting one specific device. Whether a code is required at all is decided by the keyholder per device; without one the photo is enough, with one it stays mandatory. Optionally you can enable a two-stage escalation (off by default): first a reminder, then an automatic mark as "not fulfilled" via a system entry that lands in the offence record.
Automatic Inspections
The system distributes automatic inspections randomly across the day while respecting a defined sleep window, so they stay unpredictable for the wearer. Optionally the distribution can be narrowed to a fixed trigger window; changing anything about the distribution re-rolls the current day, while inspections already sent stand and still count. After a re-lock that ends a cleaning break, an additional inspection follows 15 to 45 minutes later — within the sleep window, after just 5 to 15. It takes the place of the next inspection of the daily plan that has not been delivered yet, so the total stays the same; if none was left for the rest of the day, it comes on top. Overlap protection applies per category: while an inspection is running on one category, no second one is issued for it, whether by a human, the AI or the automation. The chastity device counts as its own category, so an inspection of the plug does not block one of the chastity device.
Photo Verification
Photo verification checks the submitted image and matches the shown device against stored reference photos. If a photo check is not confirmed, the system displays the reason — for example a missing code or a wrong seal number — so the sub can resubmit in a targeted way.
Lock Requirements & Lock Periods
Lock periods are set as fixed or open-ended, with a minimum wear time and a required device. The application monitors compliance and reports deviations. Lock requirements define bindingly what is worn and for how long.
Training Goals
Training goals are set per day, week or month and per category. Progress is measured automatically against the recorded wear time. This allows a gradual increase to be steered.
Orgasm Requirements
Requirements distinguish between an instruction as an obligation and an opportunity as a permission, each with a time window and type. The wearer confirms execution in the tracker. This keeps when and how an orgasm occurs regulated.
Setting Tasks
The keyholder defines any number of conditions and sets the deadline as a duration ("Ends in") or, behind "Pick a fixed time", as an absolute point in time — the resulting end time is displayed either way. "Time to get ready" is set separately and comes off the deadline, so the stated hours are the deadline and not the wear time; both are shown in the form and on the card. Optionally the task requires a photo as proof, which the keyholder reviews and either accepts or rejects. The keyholder overview lists the same tasks as the wearer's dashboard, with review and withdrawal directly on the card.
Penalty Log with Verdict Loop
The system automatically detects offenses such as missed inspections or wear times falling short. The keyholder then rules in a loop: dismiss or penalize. Every decision is recorded in the penalty log. The penalty is either free text or a task: "Task as penalty" leads straight into the task form, so task and verdict are created together in a single step. A completed penalty task closes the penalty by itself; if the verdict is changed or withdrawn, the task goes with it. A missed penalty task shows in the penalty log what it stood for, making it visible that one offense grew out of an earlier one. The AI keyholder can punish with a task as well.
Password Change During a Lock Period
If the password of an admin account is changed while a lock period is running, that creates an offense in the penalty log — the AI keyholder sees it and can judge it like any other. The route is recorded as well: via the forgot-password link by email, while logged in, or through another account. This is meant for solo players who let an AI guide them: resetting stays possible, but it no longer goes unnoticed. An honest note on this: anyone self-hosting their instance can delete the entry in the database — the feature is a self-commitment, not a technical restraint.
Keyholder Relationships
A keyholder can manage multiple wearers, each cleanly scoped to its own relationship. Data and directives stay separate per relationship. This allows several dynamics to be run in parallel.
AI Keyholder via MCP
An AI assistant reads the current state via the MCP protocol and issues directives within human-defined free-text rules. This serves two situations: relieving a keyholder of the routine — or acting as a virtual keyholder for a sub without a human keyholder, who connects the AI under self-set rules. The interface now reaches far: for reading, the overall picture in the keyholder dashboard, individual sessions with their segments and devices worn, device statistics, records, period summaries, the chastity trend, detected offenses, context, timeline, notes, the action log, the state of the hardware key box and the raw entries. For directives, it sets, edits and withdraws lock periods and lock requirements, requests and resolves inspections, issues orgasm directives, passes verdicts in the penalty log, sets, edits and deletes training goals, and defines the cleaning rules including the permitted daily time windows; it also maintains notes, device metadata, appointments, recurring weekly context and a health hold. Every writing action requires a reason and lands in the action log, and a preview shows in advance what a directive would change without carrying it out. The function is opt-in and off by default, and the rules stay human free text.
Operation — host & set up
The self-hoster runs the application on their own hardware, sets up users and roles, and decides on local AI and hardware extension.
Self-Hosting with Docker
The application runs as a Docker container on your own server with its own SQLite database. All data stays under your own control, with no dependency on a third-party service. Updates are applied through the published container image.
Local AI
Image recognition runs via Ollama and CLIP directly on your own server. Photos never leave your own infrastructure and are processed exclusively locally. This keeps verification entirely in your own hands.
Automatic Device Detection
Using CLIP, the local AI matches photos against stored reference images and detects the worn device automatically. This supports photo verification during inspections. Detection runs without external services.
Heimdall Hardware Key Safe
Heimdall is a physical key safe that enforces a lock period at the hardware level and only opens once the time has elapsed. The box is at MVP stage and experimental. It complements the software-side management with a physical component. If it loses contact with the server, the box card warns about the emergency opening from halfway through the radio-silence deadline onwards — early enough to do something about it; a low battery raises the same warning once it approaches the threshold. Alongside it, the card permanently displays the last contact, the approximate battery level and the firmware version.
User Management & Roles
The technical user management — creating, editing and deleting users and assigning roles such as wearer, keyholder or admin — is kept separate from the keyholder overview. The keyholder area shows sub cards, status and directives, while user management stays purely the instance admin's account administration. Anyone who only controls and wears nothing themselves works as a pure keyholder, with no own tracker to maintain.
Multilingual & Configuration
The language is configurable per account (German or English) and controls both the interface and all notifications sent by email and push. A keyholder can set a sub's language — for instance when a sub receives German mail but prefers English. Beyond that, the environment can be fully adapted to your own operation via configuration and environment variables.