Build a cloud application

Explain the use case

Specify users, inputs, outputs, stored data, and private information before choosing technologies.

I need an event registration app.
Visitors enter their name and contact details; an administrator can view and export registrations.
First confirm access rules, expected usage, and data storage, then propose a minimal version.
Test with separate resources. Do not publish to production or change production data without my approval.

What can be built depends on available tools, models, and permissions. Clarify access rules for personal data, sign-in, and payments.

Three building blocks

Inspect these in Platform. An assistant can help prepare and explain configuration; beginners do not need to fill every technical field unaided.

Native capabilities: connect platform resources

Your application server can call the Brazosd API directly. Node.js applications can also use the official @brazosd/node SDK. Connect existing files, assistants, and work history to your own interface:

A cloud function calls APIs as its own service user by default, with API and resource permissions configured by its organization. This identity represents the application. Visiting or signing into the application does not automatically grant it access to the visitor's cloud drive or sessions. Use internal application SSO below when an application needs to act with the current user's permissions.

Choose a sign-in and registration approach

Brazosd SSO (single sign-on) is recommended to reuse Brazosd registration and sign-in. Users sign in on a Brazosd page, select an organization, confirm, and return to the application. You can also keep an existing account system or build an independent one.

Internal applications receive a separate, revocable authorization and keep user credentials on the application server. Brazosd does not hand over the browser's current sign-in credentials or use this flow to give a third party access to another organization's user data.

Identity JWTs include account_id, org_id, and user_id. account_id is the recommended application user identifier: an account remains the same when it switches organizations. Applications that deliberately separate data by organization membership can instead use the combination of org_id and user_id. Signing in does not make someone an application administrator; the application manages its own roles, data access, and sessions. Members of the same organization can also use identity when only their identity is needed.

Example: a contract review SaaS

The administration area uses org-user for members of the application's organization. It accesses cloud drive files, agents, and review sessions within each member's permissions. The customer area uses identity and creates its own user records keyed by account id.

When customers upload contracts to the application, its service user can send them to an authorized agent and save results in an authorized cloud drive folder or application database. The application keeps each customer's contracts separate. Customer sign-in does not authorize access to their existing Brazosd cloud drive.

Build a contract review SaaS using the Brazosd API and SSO.
Restrict the administration area to our organization, using each member's permissions for files, agents, and sessions.
Let customers from any organization sign in for identity only, using account id as their identifier.
Each customer must see only their own submitted contracts and results.
Use the develop-cloud-apps skill, and verify both sign-in modes and data isolation in a test environment first.

A practical workflow

Agree on requirements, build with separate test functions and databases, and try valid inputs, missing fields, duplicate submissions, and access restrictions.

Before production, confirm resources, data, URL, and expected costs. Wait for successful deployment and test the actual URL before distributing it. “Built”, “deploying”, and “available” are different states.

What snapshots preserve

Snapshots preserve files and dependencies, not running processes, memory, or network connections. Finish writes and installations before capture.

Organization members can view and use organization snapshots. Check their contents before creating one. Referenced snapshots must be released by functions, agents, or sessions before deletion; creator and owner permissions also apply.

Deployment and rollback

An existing version can keep serving while a new deployment prepares. Deployment packages and history help identify versions and choose an earlier package when needed.

Rolling back application code does not automatically roll back database contents. Review and back up production data changes separately; do not mix test and production databases.

Keep it maintainable

Record the application's purpose, owner, URL, database, and maintenance instructions. Review usage and resource state. When retiring it, inspect each resource before deleting anything, because deletion may be permanent.