Ovumcy FAQ

No. Ovumcy App is the local-first mobile client for iOS and Android, and its core tracking flows work without an account, sync, or a server. A server becomes relevant only when someone wants the full self-hosted web product or optional self-hosted sync later.

The app keeps core health data on-device by default and treats sync as optional rather than mandatory for basic use.

The full self-hosted web product is the right path when browser or PWA access, operator-managed storage, or a server-side deployment model matters more than device-only simplicity.

The Ovumcy app is the no-server local-first path. Self-hosted web is the full server deployment used through a browser or installed PWA. Managed hosting is the convenience path for people who want sync and managed-only features without operating the infrastructure themselves.

The app is the fastest way to start when one device or a local-first workflow is enough.

The self-hosted web product is the stronger fit when a browser-accessible deployment, operator-controlled storage, and a visible server contract matter.

Managed hosting is a separate product tradeoff and should be evaluated from its current managed product surface rather than assumed from self-hosted docs alone.

Self-hosted sync is a separate server path for Ovumcy App, not the full web product. It gives the mobile app encrypted backup, restore, and multi-device sync through a server that is designed to store ciphertext and sync metadata instead of plaintext health records.

The current self-hosted sync backend is `ovumcy-sync-community`, which acts as the server side of the app's `Self-hosted` backup and sync mode.

This route is for people who want to keep using the mobile app while operating their own sync infrastructure instead of deploying the full browser-based web product.

Managed hosting is the path for people who want sync plus additional managed-only convenience without operating servers themselves. It goes beyond the local app path and should not be treated as identical to a standard self-hosted deployment.

On this site, the managed route is represented by `ovumcy.cloud` rather than by the self-hosted web documentation.

Exact managed-only features should be taken from the current managed product docs instead of being inferred from the open-source app or self-hosted web repositories.

Yes. The full self-hosted Ovumcy web product can run as a single Go application without Docker, but the supported quick start uses Docker Compose because it gives self-hosters a repeatable setup with health checks, persistent storage, and fewer moving pieces to assemble by hand.

The upstream README documents a manual path with Go 1.24+, Node.js 18+, a generated application secret, and direct `go run ./cmd/ovumcy` startup.

For most operators, Docker remains the recommended first deployment because it keeps the runtime contract narrow and easier to verify.

The normal update flow is to back up persistent data, pull the new image tag, restart the stack, and verify `/healthz` before trusting the rollout. The project recommends keeping image tags explicit instead of floating on `latest` in production.

For the baseline Docker path, the operator sequence is `docker compose pull`, `docker compose up -d`, `docker compose ps`, then a health check.

Public HTTPS deployments should be updated from the dedicated reverse-proxy examples so only the proxy remains exposed to the internet.

Ovumcy is not limited to one cloud-only product shape. It combines a local-first app, a full self-hosted web deployment, and an optional self-hosted sync backend while avoiding telemetry and ad trackers by default and keeping exportability visible.

That product model is different from both cloud-first trackers and device-only apps because Ovumcy keeps multiple truthful operating modes instead of forcing one vendor-hosted default.

That matters for people who want exportability, infrastructure control, or a privacy stance they can inspect before trusting the product with sensitive health data.

The answer depends on the path. App-only keeps core health data on-device. Self-hosted web stores records in the server-side database you operate. Self-hosted sync is designed so the sync server stores ciphertext and sync metadata for the app rather than readable health records.

The app README describes the mobile path as local-first with on-device storage by default for core use.

The self-hosted web product uses SQLite under `/app/data` as the default baseline, with PostgreSQL available as an advanced operator path.

The self-hosted sync backend is designed to hold ciphertext, account and device metadata, blob-size metadata, and timestamps rather than plaintext health content or recovery phrases.

No. The local-first app does not require an account for core use, and the self-hosted web product does not require a vendor cloud account to install it, sign in, or keep it running. Managed hosting is a separate optional route, not a mandatory dependency.

Ovumcy can also expose optional OIDC sign-in when an operator wants SSO, but that remains a deployment choice rather than a mandatory vendor account dependency.

The self-hosted sync backend is designed to store ciphertext, account and device metadata, blob-size metadata, and timestamps, not plaintext cycle dates, symptoms, notes, recovery phrases, or client master keys.

This is the trust model documented by `ovumcy-sync-community`, which positions the server as encrypted sync transport rather than a plaintext health-data processor.

Operators still need to secure the host, TLS, backups, logs, and any secrets around the sync deployment, because zero-knowledge transport does not remove ordinary infrastructure responsibilities.

Ovumcy uses recorded cycle data to provide estimates for the next period, ovulation, fertile window, and cycle phase. These outputs are planning aids based on recorded history, not diagnostic conclusions or medical guarantees about a specific cycle.

The interface keeps logged days visually distinct from predicted days so operators and users can tell the difference between recorded history and forecasted dates.

The upstream project explicitly states that Ovumcy is not a medical device and should not be treated as diagnostic or treatment advice.

No. Ovumcy is a cycle tracking and planning tool. It records daily information and provides estimates based on that data, but it is not positioned as medical diagnosis, treatment guidance, or emergency care advice.

People who need medical decisions should treat Ovumcy as a log and planning aid, then confirm important questions with qualified clinical guidance.

Ovumcy supports CSV, JSON, and PDF export for user-facing portability. App users should treat local exports and backup artifacts as privacy-sensitive. Self-hosted web operators should also back up the persistent SQLite volume or use native PostgreSQL backup tooling for the advanced Postgres path.

The official self-hosted guide recommends backing up the database before every upgrade and storing application secrets separately from the data archive.

Self-hosted sync improves continuity for the app, but it should not be treated as an excuse to stop thinking about backup, recovery, or export handling.

Export is useful for portability and personal review, while operator backups remain the recovery path for restoring a full deployment.

No. The export surface is intended for manually tracked records and summaries, not for packaging predictions as if they were logged facts. That helps keep exported data understandable when it is reviewed later or moved into another system.

The self-hosted export view explicitly distinguishes tracked entries from generated predictions so operators can preserve a cleaner audit trail.