Skip to content
Security architecture

Automate routine work without giving every user every permission.

Greenhaus separates workflow speed from access control. The application uses server-side authorization, role permissions, controlled workflow steps, and payment-provider boundaries. It keeps operating context connected.

Request beta access

Server-authoritative access

The application uses server-side authorization through Supabase and Postgres row-level security with permission checks. UI visibility is not the security boundary.

Role-specific access

Property managers, owners, residents, vendors, maintenance users, and internal platform users have different access paths and permission boundaries.

Workflow approvals

Sensitive financial or operational actions can be configured to require approval before proceeding.

Proposal before application

Some status-change workflows can create proposals for review instead of changing sensitive state directly.

Financial controls

Accounting periods, entitlement gates, permissions, supported MFA step-up flows, and approval logic add control around money-related operations.

Payment-provider boundaries

Stripe-powered payment and payout workflows use provider rails while Greenhaus keeps operating and payment context in the application.

Operational recovery

Authorized workflow operators can review and recover supported blocked or failed runs.