ArchDocs
Start free

00  Security

Security and access controls

Review ArchDocs sign-in, permissions, audit retention, sharing boundaries, hosting and encryption.

No credit card required

Before storing internal service names and data flows, review who can sign in, what shared links disclose and what external clients receive. These controls and deployment facts were checked on 2026-11-01.

ArchDocs is not SOC 2 certified. If your procurement process requires SOC 2 certification, ArchDocs does not meet that requirement.

Sign-in and SSO

You can configure SAML 2.0 or OpenID Connect (OIDC) SSO on Enterprise. Sign-in itself is never plan-gated. SAML assertions must be signed; that requirement is not configurable. OIDC uses state, nonce and PKCE with S256.

You can require SSO only after a successful SSO sign-in within the last 24 hours. When you require SSO, ArchDocs grants the owner password access for recovery if no administrator already has that bypass. The last administrator with that bypass cannot remove it from themselves.

Just-in-time provisioning requires the asserted email's domain to be verified for your organization. An existing account with the same email is linked. SCIM provisioning is not implemented.

Required SSO is enforced at password and Google sign-in. It does not revoke existing sessions or block refresh tokens, personal access tokens or MCP connections.

Passwords use Argon2id hashes. Password reset tokens and refresh tokens are stored as SHA-256 hashes. Personal access tokens use Argon2 hashes with optional expiry, which defaults to no expiry.

Roles and permissions

You assign Owner, Admin, Editor or Viewer roles, or use custom roles on Business and above. The server checks permissions for each protected action. Audit reading requires audit:read, which the default Editor and Viewer roles exclude. Plan entitlement is checked separately from permission.

See roles and permissions and single sign-on for configuration.

Audit log

Audit rows are written on every plan. They record sign-ins, including SSO, role changes, document and space share-link changes and other events. Reading and exporting require Business or Enterprise and audit:read.

Retention is 30 days on Free and Team, 90 days on Business and 365 days on Enterprise. A daily purge removes expired rows. You can export CSV or JSON, capped at 10,000 rows per export. Each export is itself logged.

Events can include actor, target, outcome, time, IP address and user agent, depending on the event and request context. The audit log is not a record of every canvas edit. The audit log guide explains filters and exports.

Data handling and sharing

A public space link exposes visible folder names, every non-private architecture document in that space and every object in the space, including custom field values. Folders containing only private documents are omitted. A document share link also exposes the content of non-private documents it references. Review those records before sharing a link.

Design docs and their owned diagrams do not appear in share links, public spaces or embeds. Keep the distinction between sharing an architecture diagram and granting authenticated access to a design doc.

External MCP clients receive document YAML and other content their tools return, including design doc content and journal entries. Authentication uses a personal access token or OAuth 2.1 with PKCE and dynamic client registration. Review your client's data policy before connecting it. The MCP permissions guide explains the current scope restrictions.

Connected services have their own boundaries. Read what the GitHub App can read before installing it.

Hosting and encryption

The API and PostgreSQL run on Northflank in the United States. The database has no public endpoint and connections require TLS. The web apps run on Vercel. API requests are rate limited globally.

Uploaded files are stored in Cloudflare R2. Cloudflare documents automatic AES-256 encryption at rest and TLS for transfers in its R2 data security reference, checked on 2026-11-01. Cloud-import credentials and OIDC client secrets are encrypted in the application with AES-256-GCM before storage.

Northflank states that volumes and volume backups are encrypted at rest, checked on 2026-11-01. That provider statement does not specify ArchDocs' backup schedule or retention.

What this page doesn't cover yet

We have not published our backup schedule and retention, subprocessor list, penetration test results or security headers policy. This page makes no claim about an ArchDocs backup schedule or recovery guarantee.

Send vulnerability reports and security questions to hello@archdocs.io.

99  Start

Start documenting your architecture

No credit card required