Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.mantrixflow.com/llms.txt

Use this file to discover all available pages before exploring further.

MantrixFlow security has two parts in day-to-day operations: securing user access to the workspace and securing the credentials used by pipelines.

​
What the product exposes today

Open Settings from the left sidebar. The Settings page has five tabs:
  • Profile — edit first name, last name, display name, and avatar URL
  • Organization — update org name, slug, and description (Owner only)
  • Notifications — email and alert preferences
  • Security — review verified email, change password
  • Billing — plan details, usage limits, and upgrade options
The top of the Settings page shows your account name, email, role badge (Owner/Admin), verification status, and profile completion percentage.

​
Credential handling

Based on the current connection experience and supporting product copy:
  • connection credentials are encrypted at rest using AES-256
  • credentials are not returned in normal product responses or screens
  • credentials are not meant to be written to logs
  • connections should be tested before they are saved into production workflows

​
Access model

  • users authenticate with bearer-token based application access
  • organization membership controls what resources a user can see
  • roles determine whether a user can edit settings, manage members, or build pipelines

​
Practical hardening checklist

  • use dedicated service accounts for databases and SaaS sources
  • grant minimum required privileges
  • enable SSL for database connections where the form and provider support it
  • for managed PostgreSQL providers, allow MantrixFlow’s static IP as a /32 on port 5432 instead of opening broad database access
  • rotate credentials periodically
  • keep the owner role limited to a very small set of users

​
Real-world example

A finance team connecting PostgreSQL and Stripe uses separate read-only credentials for each system, stores reporting output in a dedicated destination schema, and limits workspace ownership to one or two administrators while day-to-day operators work as admins or editors.

​
What security is not solved by the platform alone

The platform cannot compensate for an over-privileged database user, shared passwords, or unreviewed production schedules. Good operational security still depends on how your team provisions and rotates source and destination access.