Try Ovumcy App
Open source · AGPL-3.0 · Self-hosted

Self-hosted Ovumcy web on your own server

This page is about the full self-hosted Ovumcy web deployment: browser or PWA access, operator-controlled storage, and a clear server contract you can inspect before trusting it. Ovumcy runs as a single Go service, supports Docker or one binary, avoids telemetry, and keeps export, backups, and reverse-proxy boundaries visible.

It is intentionally not the same thing as the app-only path or the separate self-hosted sync backend for Ovumcy App. The supported baseline here is one private deployment, persistent data, a strong secret, and public HTTPS only through a trusted reverse proxy when the instance needs to be internet-facing.

Install docs → View on GitHub
Go · SQLite baseline · Docker · amd64 · arm64 · Latest v0.9.5
self-hosted ovumcy-web
Latest v0.9.5
Follicular · Cycle day 6 · Next period: Apr 3, 2026 - Apr 11, 2026 · Ovulation: Mar 23, 2026
Today journal March 15, 2026, Sunday
Period day
Symptoms
Cramps Headache Mood swings Bloating Breast tenderness Acne
Mood
Notes
Mild cramps today, otherwise feeling good.

What self-hosted Ovumcy means in practice.

This page covers the full browser-based web deployment, not the separate app sync backend. The supported baseline is one private deployment with persistent storage, a strong secret, and a clear split between what Ovumcy provides and what the operator still owns.

One private deployment

The baseline assumes one Ovumcy instance per deployment rather than a multi-tenant hosted platform.

Persistent storage

SQLite under /app/data is the default baseline, and the data path must stay persistent before the service is trusted with real records.

Strong secret and cookie policy

Set SECRET_KEY or SECRET_KEY_FILE before first start, then switch to COOKIE_SECURE=true when the deployment moves behind HTTPS.

Trusted proxy only when real

Enable TRUST_PROXY_ENABLED=true only when the app is actually behind a trusted reverse proxy you control.

Why this self-hosted period tracker fits real ops.

Self-hosted control without giving up the practical parts: browser or PWA access, predictions, export, and an official path from simple SQLite setups to more advanced operator workflows.

Zero-knowledge default

Your health data stays on infrastructure you control. No telemetry, no call-home dependency, and no ad-tech layer.

Browser and home install

Use the server-rendered web app in any browser or install it to a phone home screen without changing the self-hosted model.

Portable export

CSV, JSON, and PDF export keep records usable for backup, migration, and personal review instead of locking them into one setup.

SQLite first, Postgres later

SQLite is the supported baseline. PostgreSQL is available as an advanced self-hosted path through official example stacks.

Five UI languages

English, Russian, Spanish, French, and German are already supported through the current upstream product configuration.

Docker or one Go binary

Start with the container path for the easiest install, or run the application directly if a binary-based deployment fits your environment better.

Resource footprint

Operators usually want to know whether a small VPS or NAS is enough before they deploy. These figures stay tied to a real owner flow rather than a cold-start-only demo.

Measured amd64 baseline

Small by default, honest about real use.

The local Docker baseline measured about 51 MB for the image. After registration, onboarding, dashboard save, calendar edits, stats, and export on SQLite, the container settled around 50 MiB RAM on the test machine.

Image ~51 MB Post-flow idle ~50 MiB RAM SQLite baseline

No sidecar stack required

The supported path stays intentionally narrow: one Go service, SQLite by default, and no Redis, queue workers, or object storage required for the baseline setup.

arm64 compatibility was checked too

arm64 images also built and booted locally under emulation, and the same owner flow plus CSV, JSON, and PDF export passed there too. Treat that result as compatibility validation, not native hardware sizing.

For people who verify first.

If health software is going on a personal server, the repository, release history, and license should all be visible before the first deployment command runs.

Built in the open

Review the repo before you deploy.

The self-host path stays inspectable: public source, visible releases, and a clear license before anything touches your server.

21 releases Latest v0.9.5 AGPL-3.0
Open repository →

Open source under AGPL-3.0

Read it, audit it, fork it, and keep the self-host path real instead of hidden behind a managed-only product story.

Read the AGPL-3.0 license →

Docs you can verify

The source, deployment instructions, and container image references stay public before you install anything on your own infrastructure.

Open upstream README →

Browser, home screen, your server.

ovumcy-web runs as a single Go service. Open it in any browser or install it to a phone home screen while the deployment keeps storage, backups, and access control on your side.

If the goal is only encrypted backup, restore, and multi-device sync for the mobile app, use the separate self-hosted sync backend instead of this full web deployment.

If a deployment lives behind Portainer, Unraid, or Synology Container Manager, the same Docker-first baseline still applies: start narrow, then add Postgres, OIDC, or a richer reverse-proxy setup only when there is an operator reason. Questions about backups, exports, Docker alternatives, and fertility estimates are grouped on the FAQ page so the technical and product truths stay aligned.

Client surface Browser or phone home screen Server-rendered UI today, installable on a phone without changing the self-hosted model.
Desktop browser Mobile browser Home-screen install
HTTPS / private network
Application Your Ovumcy server One Go service behind your proxy, with /healthz and a narrow trusted-proxy contract.
Docker or one binary Port 8080 Trust proxy only when needed
Storage / identity
Operator options SQLite first, Postgres and OIDC later Start with the narrow baseline, then add reverse proxy, Postgres, or OIDC only when you truly need them.
SQLite baseline Postgres examples Caddy / Nginx / OIDC

Quick start and next operator steps.

Use the release-pinned quick start for the full web deployment first, then move into the dedicated install docs and reverse-proxy examples when the deployment needs public HTTPS.

Download the release-pinned compose files

Start from an empty deployment directory and fetch the tagged `docker-compose.yml` plus `.env.example` from the current upstream release.

mkdir -p ovumcy && cd ovumcy
curl -fsSL -o docker-compose.yml \
  https://raw.githubusercontent.com/ovumcy/ovumcy-web/v0.9.5/docker-compose.yml
curl -fsSL -o .env \
  https://raw.githubusercontent.com/ovumcy/ovumcy-web/v0.9.5/.env.example

The upstream release tag stays visible in the downloaded compose file through the default `OVUMCY_IMAGE` reference.

Start the stack and verify health

Launch the container, confirm the service is running, and verify the health endpoint before opening the UI.

docker compose up -d
docker compose ps
curl -fsS http://127.0.0.1:8080/healthz

If the health check returns `ok`, the baseline install is up and ready for browser access on `http://127.0.0.1:8080`.

Install docs → FAQ → Upstream README → Operations guide → Caddy example → Nginx example → OIDC / SSO →

Run it safely in production.

The official self-hosted path is intentionally narrow: HTTPS at the edge, persistent storage, a strong secret, and only the reverse proxy exposed to the public internet.

Official Caddy baseline Nginx example → 
ovumcy.example.com {
    encode zstd gzip
    reverse_proxy ovumcy:8080
}

Use the dedicated proxy stacks so only the proxy publishes 80/443 and the app stays private on the internal network.

Routine upgrade path 
docker compose pull
docker compose up -d
docker compose ps
curl -fsS http://127.0.0.1:8080/healthz

Back up the database before every version change, then verify the container is healthy before trusting the rollout.

Required env baseline

Before public HTTPS, set a strong SECRET_KEY or SECRET_KEY_FILE, keep persistent data at /app/data, and switch to COOKIE_SECURE=true behind TLS.

Persistent data and backups

Back up the SQLite volume before upgrades, keep rollback copies, and store .env plus the application secret separately from the database archive.

Trust only your own proxy

Enable TRUST_PROXY_ENABLED=true only behind your own reverse proxy and keep TRUSTED_PROXIES limited to the exact proxy IPs or subnet you control.

Keep the next question easy to answer.

After the first successful deployment, most follow-up work falls into three buckets: install discipline, FAQ-level operator truth, and broader product context.