---
title: Capawesome Cloud Security Best Practices
description: Secure your Capawesome Cloud organization — protect API tokens, limit access with roles and teams, enforce 2FA or SSO, restrict networks, and guard signing certificates.
---

# Security

Security in Capawesome Cloud is shared. We secure the platform — certifications, encryption, infrastructure, vulnerability management, and incident response are documented on our [security page](https://capawesome.io/security/){:target="_blank"}. You secure your account, your organization, and the pipelines that reach them. This page covers your side.

For the update path — signing bundles, protected channels, and rollbacks — see [Live Update security](live-updates/security.md).

## Protect your API tokens

An [API token](accounts/tokens.md) acts on behalf of the account that created it, so it can build, publish, and deploy across every organization and app that account can reach. Read it from your CI provider's secret store or a secrets manager, never from a committed file or a hard-coded string.

Create a separate token per pipeline or integration so revoking one doesn't break the rest, rotate tokens on a schedule, and revoke a token the moment it may have been exposed — including the tokens of people who leave your team.

## Give the least privilege needed

Assign the smallest [role](organizations/roles-and-permissions.md) that fits the job. A **Viewer** sees apps and their resources without being able to create a build or a deployment, which fits people who only need visibility. A **Member** can create and manage app resources but can't change organization settings or membership. Reserve **Admin** and **Owner** for the few people who manage the organization itself.

Use [teams](organizations/teams.md) to control which apps a member can reach, so a contractor working on one app never sees the others.

## Enforce two-factor authentication or SSO

[Enforce two-factor authentication](organizations/two-factor-authentication.md) for your organization. New members then need 2FA enabled before they can join, and members can't switch it off while they belong to the organization. Enforcement doesn't retroactively remove existing members without 2FA, so after enabling it, check your member list and re-invite anyone who hasn't set it up.

Alternatively, connect [single sign-on](organizations/sso/index.md) so account access follows your identity provider and offboarding happens in one place.

## Restrict network access

[Network restrictions](organizations/network-restrictions.md) limit which networks may reach your organization, by IP allowlist, country allowlist, or both. Both fail closed: if a restriction is enabled and the address or country of a request can't be determined, the request is denied.

Restrictions apply to API tokens too, so allowlist the egress ranges of your CI runners before you switch them on — otherwise your pipelines start failing.

## Store sensitive build values as secrets

Native builds read configuration from [environments](native-builds/environments.md), which hold both variables and secrets. Secrets are encrypted at rest and in transit, and their values never appear in build logs. Ad-hoc variables passed when triggering a build are not encrypted and can show up in logs, so keep them for values you don't mind exposing.

## Guard your signing keys and certificates

To build and sign on your behalf, Capawesome Cloud stores the [signing certificates](native-builds/certificates/index.md) you upload: an Android keystore, an iOS distribution certificate and provisioning profile, and a web signing key if Capawesome Cloud signs your Live Update bundles.

Keep your own backup of every key outside Capawesome Cloud, never commit one to version control, and replace it if you suspect exposure. Losing an Android keystore means you can no longer update that app in the Play Store. If you'd rather Capawesome Cloud never held your Live Update signing key, [sign bundles in your own pipeline](live-updates/security.md#sign-your-bundles) instead.

## Review audit logs

[Audit logs](organizations/audit-logs.md) record who created, changed, or deleted apps, bundles, channels, invitations, members, organizations, and subscriptions, and you can filter them by entity, action, and user. Only owners and admins can read them. Check them after offboarding someone, and whenever you find a deployment nobody on the team remembers making.

## Next steps

- [Live Update security](live-updates/security.md) — sign your bundles, protect channels, and enable automatic rollbacks.
- [API tokens](accounts/tokens.md) — create, use, rotate, and revoke tokens.
- [Roles and permissions](organizations/roles-and-permissions.md) — what each role can do.