Skip to main content
Ayakaleaf Pro runs in your infrastructure. You control its data, access, and network boundaries. This page explains the default security model. It also identifies your operational responsibilities.

​
Is Ayakaleaf Pro reliable and secure?

Ayakaleaf Pro is a self-hosted Overleaf Pro enhancement, and our source code is available at ayaka-notes/ayakaleaf-pro. Your deployment controls where services run and data resides. Security depends on your configuration and operations. Protect administrator access, enable HTTPS, and maintain backups. Thanks to OpenAI for their kind support. We will regularly use Codex Security to scan our repository for security issues and publicly share the results of vulnerability fixes.

​
Where does my data go?

By default, application data remains within your deployment:
  • MongoDB stores user and project data.
  • Redis stores cache and real-time collaboration data.
  • Local volumes or S3-compatible storage hold project files.
Only the web service is exposed by default. Internal services communicate through the Docker network.

​
Will my data be sent to or retrieved from any third parties?

Nothing leaves your deployment unless you enable a feature that requires it. Ayakaleaf Pro sends no telemetry, no usage analytics, and no crash reports. Error reporting and analytics are disabled in the default configuration. Several features never make external requests at all. Templates are stored and served from your own deployment. The Python script runner executes in the user’s browser through WebAssembly, and its runtime is served from your own web service rather than a public CDN, so script code and output never reach the network. Git Bridge is reachable only on the internal Docker network. Full project search, symbol palette, track changes, project history, and the admin panel are entirely local. Sandbox compile containers are created with networking disabled. The remaining feature requests reach the following destinations. Each request originates from the web service:
AI features are disabled by default. When enabled, chat and LaTeX error suggestions send prompts and relevant project context to the model endpoint configured with AI_BASE_URL. Optional web search sends queries to the configured Tavily-compatible service, and documentation search sends queries to DOCS_MCP_URL (default: https://docs.overleaf.com/~gitbook/mcp). Search results can be included in requests to the model provider. See AI Integration for configuration and user controls.
GitHub integration contacts github.com and api.github.com. It is enabled per user by linking a GitHub account, and the authorization requests the read:org, repo, and workflow scopes. Pushing uploads full project file contents as Git blobs, which are then assembled into trees and commits. It also performs branch, reference, compare, and merge operations, and reads the linked account’s profile, organization memberships, and repository list. Project content leaves your deployment in both directions — treat a linked GitHub account as an export path for every project attached to it.
Zotero integration contacts www.zotero.org for authorization and api.zotero.org for library data. It is enabled per user by linking a Zotero account. The OAuth handshake and the user’s API key are sent. Reads are one-directional: reference libraries are pulled in as BibTeX, and no project content is uploaded.
Mendeley integration contacts api.mendeley.com for both authorization and library data. It is enabled per user by linking a Mendeley account. The OAuth handshake requests Mendeley’s all scope — the only scope its API offers — but Ayakaleaf only ever performs reads: reference libraries and group libraries are pulled in as BibTeX, and no project content is uploaded. Access tokens are refreshed automatically; when Mendeley revokes a grant, the stored credential is discarded and the user is asked to link the account again.
Documentation pages are retrieved from https://learnwiki.overleaf.com, configurable with WIKI_URL. Requests are made by the web service, not by the user’s browser, so the upstream wiki sees your server and never your users’ addresses. Only the requested page title is sent, and responses are cached on disk. Point WIKI_URL at your own mirror, or block the destination, if outbound documentation traffic is not acceptable.
Email delivery contacts whatever SMTP server or mail API you configure; there is no default. Recipient addresses and message contents leave your deployment, including password reset and invitation links.
Two optional checks are disabled by default. The compromised password check is inactive unless HAVE_I_BEEN_PWNED_ENABLED is set; when enabled it sends the first characters of a SHA-1 hash of the password to api.pwnedpasswords.com, never the password itself. CAPTCHA verification is inactive unless a reCAPTCHA site key is configured, and contacts www.google.com when active.
Single sign-on reaches only the identity provider you supply, and what travels there depends on the protocol. With LDAP the web service connects to your directory directly: it binds with the service account you configure, searches under the base, filter, and attribute list you define, and verifies the password entered on the login form against your directory, so that the username and password reach the directory server. Enabling directory-backed contacts causes an additional search to populate the contact list. With OIDC the web service exchanges the authorization code at your token endpoint and then calls your user-info endpoint, requesting the openid profile email scopes by default; this is configurable with OVERLEAF_OIDC_SCOPE. With SAML the authentication request travels through the user’s browser to the identity provider rather than over a direct server connection. In all three cases the user’s name and email address arrive from the provider rather than being sent to it, and are then stored on the local user record.
Third-party credentials — OAuth tokens and API keys — are held in MongoDB on the user record, encrypted with AES-256-CTR under a per-record salt and initialization vector. They are never stored in plaintext and never written to logs. The encryption key comes from ${PROVIDER}_CIPHER_PASSWORD if set (like Zotero and Mendeley); otherwise one is generated on first use and persisted inside your data volume with owner-only permissions. Back up that key together with your data volume: if it is lost, stored credentials cannot be decrypted and every user must link their accounts again.
Files linked from a URL are fetched by your deployment on the user’s behalf, so the destination is whatever address the user supplies. Linked URL files are disabled unless you add url to ENABLED_LINKED_FILE_TYPES, and the default configuration does not include it. External ZIP and TeX imports through the Open in Overleaf API also use the same linked-url-proxy component. Direct requests resolve the target hostname and reject restricted network ranges, subject to configured allowed-resource exceptions. With OVERLEAF_LINKED_URL_OUTBOUND_PROXY configured, the outbound proxy resolves hostnames, so it must enforce internal-network restrictions itself; application network checks only apply to URLs containing IP addresses. See External URL — Outbound Proxy for details. These requests fetch the supplied URL rather than uploading project files.
If your policy requires an outbound allow-list, permit only the hosts whose features you have enabled — github.com and api.github.com for GitHub, www.zotero.org and api.zotero.org for Zotero, api.mendeley.com for Mendeley, learnwiki.overleaf.com or your own WIKI_URL for documentation, api.pwnedpasswords.com for the password check, www.google.com for CAPTCHA, plus your own mail server and identity provider. If AI features or search are enabled, also allow the configured model, web search, and documentation MCP endpoints. Deny destinations that are not required by your enabled features. Where egress must be inspected or logged centrally, the GitHub, Zotero and Mendeley integrations can each be routed through an HTTP proxy by setting GITHUB_SYNC_PROXY_URL, MENDELEY_PROXY_URL and ZOTERO_PROXY_URL. Linked URL fetching and remote imports can use OVERLEAF_LINKED_URL_OUTBOUND_PROXY. Files linked from a URL cannot be constrained to a host list, since the destination is chosen by the user at the time of the request; restrict that feature through the proxy component’s own allowed-resource setting, or leave it disabled.
If you deploy Ayakaleaf Pro with s3.md storage enabled, is the data stored in S3 encrypted?No. The data is not encrypted. All history chunks, template files, PDFs, and other files are stored in plaintext. If you use a third-party external S3 storage provider, please pay close attention to data security and privacy.

​
Are project compiles isolated?

Ayakaleaf Pro supports sandboxed compiles. Each compile runs in a separate container. Sandbox containers have no network access by default. This reduces exposure to internal network resources. Sandboxed compiles require access to the host Docker socket. Restrict host administration to trusted operators.

​
Can I trust CI builds and container images?

GitHub Actions builds and publishes Ayakaleaf Pro container images. Images are available from the public GitHub Container Registry. Images support amd64 and arm64. Docker selects the matching architecture when pulling an image. Do not use the latest tag in production. Pin an explicit version, preferably an image digest. Test every upgrade in a non-production environment. Verify the image, configuration, and integrations before rollout.

​
Is the code open source?

Ayakaleaf Pro and related feature repositories are publicly available. This allows users to review changes and trace upstream sources. Public source code supports independent review. It does not, by itself, guarantee reproducible release builds. Before upgrading, review:
  • The release tag or commit.
  • The image version or digest.
  • Third-party dependencies and license requirements.
Last modified on October 5, 2026