RumataHow Rumata fits together
Connect your frontend, managed backend, database, files and workflows, and understand how each runs.
Step-by-step guidance.
Before you start
- Familiarity with a Rumata project and factory.
One product, connected parts
The frontend is the interface people use. A managed backend service runs your application API, account checks and business logic. PostgreSQL stores structured records; project storage stores uploaded or generated files. Workflows coordinate automation, AI and long-running jobs.
| Part | What it owns |
|---|---|
| Project | Application resources and collaboration permissions. |
| Factory | The workspace where you build an application and manage its resources. |
| Frontend | Browser screens and the published website. |
| Backend service | An API, a container application, a server-rendered application, or a background worker. |
| Database | Structured records, relationships and application-user ownership. |
| Project storage | File objects such as images, attachments and exports. |
| Workflow | An automation or durable job connecting triggers, AI, queries and other steps. |
| Activity or connector | A reusable operation invoked by a workflow. |
| Secret | A protected credential bound to an authorized service or integration. |
| Billing account | Subscriptions, shared allowances, purchased resources and usage. |
Choose where the work runs
| Workload | Usual starting point |
|---|---|
| An application API, saved records, user accounts or authorization | A managed backend with the database binding enabled. |
| Existing software or a third-party container | A managed service from its image or repository Dockerfile. |
| AI generation, scheduled automation, ETL or a long-running pipeline | A workflow, called by the backend when the app needs it. |
| A website with no application data or server logic | A frontend; add a backend when the product needs one. |
| An existing combined server-rendered app | Preserve its architecture and identify the service that serves its pages and API. |
A backend can call a private workflow for delegated work. Routine record creation, account checks and file signing can stay in the backend; they do not require a separate workflow for each endpoint. See Backend services and Connect backends and workflows.
Follow one user action
- A person opens the frontend and submits a form, such as creating a private note.
- The frontend calls its configured backend API. The binding selects the private development endpoint or the deployed service.
- The gateway applies the endpoint’s Rumata access rules. The backend separately verifies the application session and permission to change the requested record.
- The backend validates the input and writes to PostgreSQL using its server-side database binding. It may authorize a direct file upload or start a workflow for asynchronous work.
- The frontend displays the result. Reload and read it again to prove persistence; for a job, follow its status to the completed output.
For a workflow feature, inspect its trigger, access, response mode and run history. For a backend feature, inspect its endpoint, development or deployment status, logs and application response. Follow the path your app actually uses.
Run and connect a backend
Open System Explorer → Services to configure a container image, repository Dockerfile, or native Node.js/Python service. A web service exposes HTTP; a background worker can run without an HTTP endpoint. Development uses working-tree files on your development machine. The deployed service runs independently.
For a separate frontend and API, `rumata.backends.json` holds service bindings. Preview uses the development route; the published frontend uses its reviewed production binding. The file contains addresses and service IDs, never database credentials or service keys. See Frontend bindings.
Separate lifecycles matter
Stopping a development machine stops its preview and development processes; it does not by itself stop the published website, deployed backends or published workflows. Each has its own status and resource allowance.
An on-demand backend or database may sleep and wake for a permitted request. An HTTP-disabled worker needs a suitable worker runtime policy. A page loading successfully does not prove that its API, database or job is healthy. See Idle hibernation.
Application users and workspace access
Your Rumata account and team permissions control development resources. Your application’s accounts control the people using the product. A backend can use the starter’s native email/password accounts or a sign-in method appropriate to the app; it must enforce record ownership on every protected request.
A public service endpoint does not make private records public when application authorization is enforced. A platform API key belongs on the server and cannot replace application-user authorization. Test two users and signed-out requests before publishing. See Accounts and Test access.