RumataPlatform capabilities
The cloud capabilities Rumata provides, and the functional capabilities you build from them, such as passwordless login, bots, roles and integrations.
Step-by-step guidance.
Before you start
- Read Fact statuses for the meaning of Provided and Buildable.
Cloud capabilities
These are what the platform provides. Every functional capability below is derived from them.
| Capability | What Rumata provides | Detail |
|---|---|---|
| Compute | Any container image, a repository Dockerfile, or native Node.js and Python source. Any language or framework that runs in a container. HTTP services and background workers, with on-demand or always-on policies. | Backends |
| Data | Managed project PostgreSQL with a factory schema for application data. Any other database, such as MongoDB, can run as a service with a persistent disk. Export, backup and recovery in Studio. | Database |
| Files | Managed object storage with signed uploads and downloads, listing and deletion. | Storage |
| Orchestration | Workflows with manual, HTTP and cron triggers, outbound HTTP to any API, connectors, and durable asynchronous jobs. | Workflows |
| AI | A native agent step with files, images, callable tools and caller or owner billing. | AI steps |
| Delivery | Immutable source builds, reviewed factory releases, deployments with logs, frontend publishing, gateway access control and API keys. | Backends |
| Secrets | Server-side secrets bound by name to services and workflows. | Backends |
| Operations | Logs, monitoring, usage metering, plan allowances and team access. | Billing |
Functional capabilities
Rumata hosts your application logic, so a feature does not need a built-in module to be available. Provided means a ready module exists. Buildable means you write it on the cloud capabilities listed.
| Functional capability | Status | Built from |
|---|---|---|
| Email and password accounts | Provided | Native accounts module on a backend and PostgreSQL. See Accounts. |
| Passwordless, one-time-code, magic-link or phone login | Buildable | A backend, a database and an outbound message provider. See Passwordless login. |
| WhatsApp, SMS or Telegram bots | Buildable | Telegram has connector operations and an On message trigger. Complete bot behavior uses a workflow or backend and, when needed, the native agent step. Other providers can use HTTP integration. See Messaging bots. |
| Per-customer data and prices, hidden from other customers | Buildable | Backend authorization on every read and write, with owner columns in PostgreSQL. |
| Staff roles and permissions inside the app | Buildable | A roles table in PostgreSQL and backend checks on the verified user. |
| Integration with an accounting or ERP system | Buildable | Workflow HTTP calls, a connector, or a backend client, using server-side secrets. |
| Bilingual and right-to-left screens | Buildable | The frontend. Rumata does not constrain it. |
| Product photos and documents | Provided | Managed storage with signed links. See Storage. |
| Scheduled jobs, ETL and pipelines | Provided | Cron and durable workflows. See Workflows. |
| An assistant that reads and changes app data | Provided | The agent step with callable data tools. See AI steps. |
| Software in any language, or a third-party server | Provided | A container service. See Backends. |
Passwordless login
Customers can sign in with a one-time code or link sent to their phone, with no email and no password. The built-in accounts module covers email and password only, so this is custom application authentication. It is independent of the module and of Rumata’s own sign-in.
- Receive the identifier: a phone number typed in the app, or a message sent to your bot’s webhook.
- In your backend, store a short-lived, single-use code or link token with an expiry and attempt limit, against the customer record in PostgreSQL.
- Send it through your message provider (WhatsApp, SMS or email) with an outbound HTTP call, a workflow or a connector, using a server-side secret.
- Verify the code or token in the backend, mark it used, and issue the app’s own session. Enforce ownership from that session on every request.
Messaging bots
The connector catalog includes Telegram Send message/Get updates, Slack Send message/List channels, and Discord Send channel message. Telegram also has an On message trigger; Slack has an On event trigger. Discover the actual operations and bind the provider credentials as secrets. A complete bot still needs application logic, provider webhook registration and appropriate request verification. Other providers can use an HTTP workflow or backend route plus outbound HTTP. The native agent step can decide the reply. See Connector catalog.