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, Git sources, and AI keys
• review who can edit variables, view logs, trigger deploys, or change billing

For role and permission details, see Organizations and Permissions.

Also protect each user account:

• enable two-factor authentication (2FA) with an authenticator app (TOTP)
• review the sign-in history for the last 7 days in Account
• keep sign-in and password change notifications enabled

See Account security.

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 you save a new secret as an environment variable, the project instances restart automatically to read the updated value; see Environment variables.

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 databases (PostgreSQL, MariaDB, and ClickHouse/Analytics) and Valkey services show connection details in the console. The application must receive these values through environment variables.

Attention points:

• the application user should not be treated as root or superuser
• outside the joint template deployment, DATABASE_URL (or the equivalent variables) must be configured manually in the HTTP project
• persistent storage remains relevant even when the application is stopped
• version upgrades can cause temporary unavailability
• do not rely on automatic backups: keep your own backup routines (for example, periodic dumps) and test restores

Network and public exposure

Public HTTP projects receive a Zenifra URL and can use a custom domain according to the plan. For internal apps, admin tools, workers, or automations that do not need external traffic, create or change the project to exposure: private to avoid a public domain.

When the project must remain public, review IP access controls, available starting on the Premium Plus plan; see Network access.

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

The platform shows each user's sign-in history and the last access and last IP of each API Key. When formal audit trails of application operations are required, define internally what must be recorded and record those events in the application itself.

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 ([email protected]) with objective context

To follow platform availability and ongoing incidents, check the status page at status.zenifra.com.

Next steps

• Checklist before production
• Limits and quotas
• Organizations
• Project configuration

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.