Security

Security, privacy, and reliability

Security on Zenifra combines platform controls, correct project configuration, and good practices from the team operating the application. This page describes the public points to review before running important workloads in production.

Access model

CPF and CNPJ accounts operate through organizations. Inside an organization, access can be separated by roles and granular permissions.

Use organizations to:

  • separate personal, company, and client projects
  • invite members without sharing credentials
  • limit access to projects, databases, billing, GitHub, and AI keys
  • review who can edit variables, view logs, trigger deploys, or change billing

For role and permission details, see Organizations and Permissions.

Secrets and environment variables

Application secrets should stay out of source code. Use environment variables in the console to store:

  • DATABASE_URL
  • external service tokens
  • private keys
  • API keys
  • private registry credentials

Best practices:

  • do not commit production .env files
  • use consistent names across local and production environments
  • rotate credentials when someone leaves the team
  • separate keys by environment, customer, or integration
  • grant edit permission only to people who really need it

Warning: Environment variables can be read or changed by members with project permission. Do not place secrets in frontend code, public artifacts, public Docker images, or build logs. When replacing a secret, publish a new version or restart the application when needed so the process reads the updated value.

API keys

Projects and resources can expose keys used for automation or integration. Treat these keys as production secrets.

Recommendations:

  • copy and store the key when it is displayed
  • do not send keys in messages, public issues, or logs
  • use one key per integration when possible
  • restrict global API keys by IP when the automation has a fixed source
  • grant only the RBAC permissions required by the automation
  • remove or replace keys that may have leaked
  • document internally who owns each key

Risk: Zenifra API keys allow automations over organization resources. Do not use these keys in browser-executed web applications or publicly distributed mobile clients; use them only in controlled environments such as servers, pipelines, and internal tools. If a leak is suspected, revoke the key and create a new one.

Database

Managed PostgreSQL and MariaDB databases show connection details in the console. The application must receive these values through environment variables.

Attention points:

  • the application user is not root or superuser
  • DATABASE_URL must be configured manually in the HTTP project
  • persistent storage remains relevant even when the application is stopped
  • version upgrades can cause temporary unavailability
  • backup, retention, and restore requirements should be validated according to the project needs and subscribed plan

Network and public exposure

HTTP projects receive a Zenifra URL and can use a custom domain according to the plan. For internal, administrative, or staging applications, review IP access controls when available.

Before production:

  • validate DNS and domain
  • use HTTPS on public endpoints
  • limit administrative access
  • avoid exposing internal dashboards without authentication
  • treat database URLs and tokens as sensitive data

Logs and operational audit

Logs help investigate failures, but they can also leak data if the application records sensitive information.

Avoid writing to logs:

  • passwords
  • tokens
  • authorization headers
  • personal documents
  • complete payloads with sensitive data

When formal audit trails are required, define internally what the application must record and validate with support which platform events are available for your plan.

LGPD and personal data

Zenifra should be used in a way compatible with LGPD and your organization's data policy. The application published on the platform remains responsible for defining legal basis, minimization, retention, and deletion of the data it collects.

Best practices:

  • collect only required data
  • document retention and deletion
  • protect personal data in logs and integrations
  • review member permissions frequently
  • keep an internal channel for data subject requests

Incidents

If you suspect a key leak, unauthorized access, or abnormal behavior:

  1. rotate affected keys and passwords
  2. review organization members and permissions
  3. inspect application logs
  4. reduce public exposure if needed
  5. contact support with objective context

Next steps

FAQ

Does Zenifra replace application security?

No. The platform provides operational controls, but application authentication, end-user authorization, input validation, and data protection remain the project's responsibility.

Can I share one account between people?

It is not recommended. Use organizations, invitations, and permissions to separate access and keep operational traceability.

Where should I store secrets?

Store secrets in the console as environment variables or in your organization's internal vault. Never version secrets in the repository.

Organization API Keys

Create global organization API keys for automation, the Zenifra CLI, and custom integrations with RBAC and IP allowlists.

Limits and quotas

Known Zenifra operational limits for API, variables, instances, database, logs, metrics, deployment, and AI.

On this page

Security, privacy, and reliabilityAccess modelSecrets and environment variablesAPI keysDatabaseNetwork and public exposureLogs and operational auditLGPD and personal dataIncidentsNext stepsFAQDoes Zenifra replace application security?Can I share one account between people?Where should I store secrets?