Security and trust

Otalan is built for teams that need OTA speed without giving up release control. The safety model is simple: only compatible bundles can be served, bundles are validated before activation, credentials are scoped by job, and operators can pause or roll back a release without shipping a new native binary.

This page is a public summary of the v1 security posture. It is not a security certification.

Release safety model

Otalan is designed to reduce the blast radius of a bad OTA release:

• each release targets one exact appId, platform, channel, and runtimeVersion
• only one bundle can be active for that exact target at a time
• failed validation keeps the previous active bundle in place
• staged rollout can limit exposure before a full release
• pause and rollback are available from the same release history

That model does not replace app testing. It gives the release team a controlled path for compatible web asset updates.

Credentials are split by job

Otalan separates credentials so one key is not responsible for everything:

• OTA App Keys are used by installed apps for runtime update checks and confirmation.
• OTA Publish Keys are used by @otalan/cli and release automation.
• Publish keys should never be shipped in frontend or mobile app code.
• Sensitive credentials are not shown back to users after creation.

Keep publish credentials in trusted release tooling, CI secrets, or the dashboard. Keep app credentials limited to the installed app runtime.

Bundle validation

The dashboard and @otalan/cli handle upload details automatically. Uploaded bundles are validated before activation.

The validation layer rejects or bounds:

• path traversal and absolute paths
• Windows drive-letter paths
• symlink entries
• encrypted entries
• unsupported compression methods
• nested ZIP files
• forbidden executable/source-map style entries
• duplicate archive paths
• ZIP64 and multi-disk archives
• excessive compressed size
• excessive uncompressed size
• excessive file count
• excessive path length
• excessive compression ratio
• generated Expo manifests over 256 KB

If validation fails, the previous active bundle remains active.

Runtime safeguards

Runtime delivery is protected by:

• authenticated OTA App Key requests
• exact tuple matching before a bundle is served
• active subscription checks before publishing and billable delivery
• bounded request metadata and release metadata
• rollout percentage, pause, resume, and rollback controls

Contact Otalan before unusually large or time-sensitive rollouts.

If a release goes wrong

For a compatible web asset problem, the normal response is:

1. pause the active release if more exposure should stop immediately
2. roll back to a previous known-good bundle in the same tuple
3. confirm the app receives the restored bundle on the next eligible check
4. publish a corrected bundle when ready

If the problem depends on native code, native plugins, permissions, entitlements, or a different runtime version, ship a new store binary and publish future OTA bundles on the new runtime line.

Deletion and operational records

Archiving an app is reversible and does not delete bundle records or stored bundle files. Deleting an app removes its app-scoped release history and queues related bundle archive and Expo asset objects for housekeeping deletion from object storage.

Bundle files can also be deleted from a bundle row. A deleted bundle file cannot be served and cannot be used as a rollback target.

Otalan may keep operational metadata needed for release history, usage and billing records, audit, security review, abuse prevention, and support. For privacy, deletion, or security requests, contact contact@otalan.com.

Contact

For security reports, privacy requests, or deletion requests, contact contact@otalan.com.

Include enough detail to reproduce security issues: affected area, customer impact, request shape, expected behavior, observed behavior, and whether credentials or customer data may have been exposed.