The hard part of an internal tool isn’t the API. It’s the second user

Description and use

A lightweight container that delegates heavy services to external URLs provides an internal tool with multi‑user support, tenant isolation, and audit logging, eliminating subscription costs.

Problem

Internal tools often become costly subscriptions when they rely on vendor services for glue, but the real challenge is adding a second user with proper isolation, authentication, and auditability.

Outcome

The tool now runs on a small container, keeps data on the LAN, supports multiple users with proper isolation and audit logs, and eliminates subscription costs by using existing infrastructure.

Workflow

• 1. Design container to be lightweight (239 MB) and delegate heavy dependencies to external URLs.
• 2. Store all data locally; photos never leave LAN except to the vendor API.
• 3. Enforce tenant isolation by making tenant a required field in all data access APIs.
• 4. Remove default tenant value; require explicit tenant assignment to prevent unauthenticated access.
• 5. Implement three auth modes: solo (no auth), signin (app‑managed sessions), proxy (forward‑auth).
• 6. Separate seat (billing entitlement) and role (trust level) checks in permission logic.
• 7. Add support access via scope switch instead of impersonation, logging both operator and client actions.
• 8. Display active auth mode and scope banner in UI for transparency.

Evidence

The container stays small (239 MB) because it contains no model weights, no browser, no search index. It is Python, SQLite and templates.

Source

Anonymous, unauthenticated requests constructed a user object without overriding it — so an unauthenticated request resolved to the default tenant's data.

Source

The default is no authentication, and the failure is silent.

Source