How Mekovault is built and operated

01Infrastructure

Mekovault runs on AWS Lightsail in us-east-1, on four machines connected by a private network. Only one of them receives Internet traffic.

• Administration exclusively over Tailscale (WireGuard). No host has SSH open to the Internet.
• ufw firewall active on every machine with a default-deny policy.
• Internal services (PostgreSQL, Redis, RabbitMQ, Infisical, Grafana and the FastAPI processes) listen on loopback or the private interface. nginx is the only process serving public traffic.
• Cloudflare terminates TLS and filters traffic before it reaches nginx.

02Service architecture

The web interface is a Next.js 16 application. The backend is a set of FastAPI services on Python 3.12 with async SQLAlchemy, each with a narrow responsibility.

Events and background jobs

• Services communicate through events on RabbitMQ, using the topic exchange mekovault.events.
• Heavy work (provisioning, deletions, exports) is recorded in a job ledger in PostgreSQL and executed by a single worker.
• Each job retries with exponential backoff. Its steps are idempotent: re-running a completed step does not produce duplicate effects on the directory.
• When a job exhausts its retries an alert is raised and the job stays visible with its last error for manual intervention.

03Identity and session

Mekovault users (IT administrators, approvers, resellers) authenticate with Google OAuth or with email and password. The session is designed so that a stolen token is short-lived and revocable.

Practical consequence: a leaked access token expires within 15 minutes at most; the refresh token cannot be exported from the browser; and revoking the jti in Redis ends the session immediately, without waiting for anything to expire.

04Multi-tenant isolation

Mekovault is multi-tenant: several customers share the same infrastructure. Isolation between them is enforced in independent layers, so a defect in one layer does not expose another customer's data.

05Provider credentials and usage audit

To operate on your directory, Mekovault receives credentials with administrative permissions: the JSON of a Google Service Account with domain-wide delegation. They are the most sensitive asset we handle.

• Stored encrypted in Infisical (self-hosted, on mekovault-vault), in a dedicated project per tenant.
• Never written to the database, logs or API responses. The database stores only a reference to the secret.
• Loaded into memory at the moment of calling the provider and discarded when the operation ends.

Immutable record of every use

Every call to Google with a customer's credentials writes a row to the credential_usage_log table.

• The table has PostgreSQL triggers that reject any UPDATE or DELETE. Not even the Mekovault team can edit or remove an individual row.
• Each row has a deterministic id derived from the operation. A retry of the same job does not produce a second row, so the log neither inflates nor contradicts itself.
• A burst of failures against a tenant's credentials raises an alert to the operations team.

Retention

Export for auditors

The log exports as CSV or JSON. Each file is signed with HMAC-SHA256 and includes the identifier of the key used, so an auditor can verify the file was not altered after it was generated.

06Permissions Mekovault requests

Mekovault asks only for the permissions it needs to manage users, groups and organizational units. It does not request access to mail, files, calendar or any user content.

Calls are made with the Service Account impersonating the delegated administrator the customer designates when connecting the domain. That administrator is recorded in every credential_usage_log row.

07Initial passwords and resets

• When Mekovault creates an account or resets a password, the temporary password is visible to the administrator who executed the action for 15 minutes.
• After that it is purged from the system. It cannot be recovered: if lost, a new one is generated.
• Passwords are never written to logs, events or the credential usage log.

08Tenant deletion

A customer can request full deletion of its tenant (right to erasure, GDPR art. 17 and Chilean Law 21.719). The process is designed so credentials disappear before any other data.

1. A tenant administrator requests deletion. The request is queued as a job.
2. The tenant becomes inaccessible immediately: its sessions and new sign-ins are rejected.
3. The job revokes the tenant's secrets and deletes its Infisical project. From this point Mekovault can no longer call the customer's directory.
4. Only then is the tenant's data deleted in cascade from PostgreSQL: users, requests, tickets, configuration.
5. The deletion is recorded in the platform audit trail.
6. Administrators receive a confirmation email detailing what was deleted.

09Addons: modules with limits

Provider connectors and other extensions are packaged as addons. A defective addon must not be able to degrade the whole platform, and the addon registry enforces that rule.

10Perimeter and browser

11Operations and observability

• A database backup is taken before every deploy.
• Services are deployed in a controlled way; a failed deploy is rolled back to the previous backup.

Hygiene timers

12Security layers summary

13What is in progress

We prefer to say what is missing before a questionnaire asks. These items are being worked on and should not be assumed to be in place until this page moves them to the relevant section.