Rosie — architecture, security, operation

Rosie is a vanilla-JavaScript progressive web app. The application runs as a Node process on a Debian instance at Infomaniak in Switzerland, fronted by Caddy as a reverse proxy with automatic certificate management. Persistence uses libSQL/SQLite on the same instance (WAL mode), object storage via the S3-compatible object store at Infomaniak. The service worker uses a CACHE_PREFIX per release. A protective service sits in front of the public website — it holds no data; the API talks directly to the Swiss instance.

• Main domain: rosie-app.ch (including www).
• Alias / mirror: rosie-planer.com — as a 301 redirect. Expect a cache window of about two minutes that resolves on its own. To check the origin immediately, use ?cb=<random>.
• App subdomain: the application runs under its own name pointing directly at the Swiss instance (“DNS only”, with no intermediary service).
• No wildcard record. *.rosie-app.ch does not exist — an invented name does not resolve. That is deliberate and rules out subdomain takeover.
• The protective service in front covers the public website only; it holds no customer data.

• sw.js with CACHE_PREFIX, stamped from shared/version.mjs (scripts/sync-version.mjs).
• Upstream cache: about two minutes of lag after a deployment, which resolves on its own.
• immutablecache header for versioned assets.
• Lazily loaded libraries via _loadVendor — XLSX, html2canvas.
• iOS splash screens must be PNG — WebP dropped in release r168.
• No background sync — deliberately: a replay without an open tab would have no fresh token and, without idempotency keys, would risk duplicate writes. The chat outbox only flushes while the app is open (see docs/OFFLINE.md).
• Web push on iOS works only in the installed app — enforce adding it to the home screen.

• VAPID keys (public and private) are stored as secrets on the instance under /etc/rosie/env.
• subscribeToPushNotifications is an idempotent upsert.
• Quiet hours are respected.
• On or off per alert category: bounty · planPublished · adminAlert · messages · absenceResult.

• Outbound HTTPS on port 443 only.
• Allow for rosie-app.ch and the app subdomain. No other destinations are needed — the app does not call any service at the customer on its own.
• No inbound ports.
• No WebSocket required — the app polls every 60 seconds.

Delivery via SMTP to a Swiss mailbox at Hostpoint. The sender of all system email is support@rosie-app.ch — an address you can reply to, not a no-reply dead end. SPF, DKIM and DMARC are configured; we recommend testing delivery against the customer’s spam filter once after initial setup.

• iOS 14.5+, Android 8.0+.
• A web app — no app store package.
• MDM can configure the preferred browser, home screen web clips and trusted sites .
• Note: Web push on iOS requires the installed app; iOS splash screen in PNG (not WebP).

Migrations live under database/migrations/ , numbered consecutively, and are applied forward only. The current state is in the directory itself — this page deliberately names no number, since it would be wrong by the next release. Every run is followed by a schema check. The migrations are built so that an empty database can be rebuilt entirely from them.

• Automatic backups of the database, encrypted and stored off site.
• A 30-day recovery window with hourly recovery points (RPO of one hour or less).
• Object storage is backed up separately.
• A full data export per tenant, at any time from the administration interface.
• No geographic redundancy. One production instance is run deliberately — a restart or an update means a short outage. That is a known and accepted trade-off, and it can be added later without changing the architecture.

Every release has a tag checkpoint-rNNN-deployed in the source control system, so it can always be shown which version was live and when.

• Server-side tenant scoping — tenant_id in every query.
• The in-memory tenant globals are cleared on sign-out via _resetTenantCalendarData() (six calendar globals).
• Cross-tenant leak tests are pinned by regression cases.
• Persistence is triggered by a tenant marker companySettingsDirty.

• X-Worker-Version (r166 A10), X-Request-Id in every response.
• Web Vitals → /api/analytics, sent with keepalive, Do Not Track respected.
• A personal-data scrubber runs before analytics.
• k-anonymity of at least 4 for aggregate charts.
• Logs sit on the instance (systemd/journald) and are evaluated by the vendor; an external uptime monitor checks availability and raises alerts.

• LCP / CLS / INP targets as the performance budget.
• Layout-shift fix: width / height on <img>tags.
• Lazily loaded libraries via _loadVendor — XLSX / html2canvas.
• Battery saving: polling pauses when document.hidden (paused when hidden).

• AI provider: enabled per tenant; one fixed service per purpose, with no automatic fallback. Which provider is used is stated in the sub-processor list of the data processing agreement — not here, so that this page does not become wrong when the provider changes.
• Rate limit: 30 requests per hour per user.
• The personal-data sanitiser strips email addresses, social security numbers, IBANs, phone numbers and dates before every call to the AI service.
• Scheduled AI jobs 0 2 / 0 4 for the task pattern learner — prompts without staff.id.
• Speech recognition: handled by the browser (Web Speech API); depending on the browser or operating system, the recording is sent to its own speech recognition service — ROSIE neither receives nor stores any audio recordings. For command recognition, only the recognized text goes to the AI service, with consent (Art. 6(6) revFADP).

Optional modules: Quality management (QMS), Voice-to-Schedule, Payroll preparation & finance, Smart Matchmaker, Workload radar, Regional network. Enabled per tenant under Administration → Tools.

• A global Escape key and focus trap .
• ARIA progress bar .
• Four interface languages: DE / FR / IT / EN.
• 14 chat languages for internal communication — the translation runs on the device.

• Secrets live in /etc/rosie/env on the instance, readable only by the service account: the session signing key, the VAPID key pair, and credentials for object storage, SMTP and the AI service.
• Rotate the signing key annually.
• Rotating the VAPID keys invalidates push subscriptions (a known limitation).
• Password hashing: PBKDF2-SHA-256 with a salt, in four chained rounds of 100,000 iterations each (400,000 in effect).

A tenant is set up by the vendor on the Swiss instance. No installation is needed at the customer — no servers, no agents, no inbound ports. What follows is the list of items that genuinely sit on the customer side.

Procedures exist for: sign-in errors · database errors · deployment errors · email delivery · AI outage · push delivery · migration errors.

• TLS 1.3.
• AES-256 at rest. Particularly sensitive free-text fields are additionally encrypted field by field.
• Data hosted in Switzerland (Infomaniak): compute, database, object storage and backups. The protective service in front of the public website and the payment provider are named in the sub-processor list of the data processing agreement.
• Data processing agreement in place.
• No cookies, no tracking — Do Not Track is respected.
• Key destruction as the operational revocation; erasure within 30 days of the end of the contract, with written evidence.
• SSO (SAML/OIDC) is not available and under evaluation; no committed date exists. Sign-in uses email and password, optionally with TOTP.