Source: https://buildwhat.ai/docs?doc=delivery%2Fbackend-services
Language: en-US
Last updated: 2026-11-13T00:00:00.000Z

# Backend services and deployment

## Current scope

Enabling Backend connects a project to supported database, authentication and file APIs for development previews. It does not provision an arbitrary application server or a stack of middleware. BuildWhat does not currently offer platform production application hosting, production data services, or a public self-hosted edition of the BuildWhat platform. Check [current delivery capabilities](/pricing#delivery-capabilities).

## Development and production

Development data is for building and testing. Studio previews run in the project workspace; exporting source and running it on your own computer is a separate workflow. The browser preview's scoped APIs and credentials are not a public database connection for an exported app.

The external static publishing channel uploads site files to a verified hosting connection. It does not automatically provision an application server, database instance, Redis or message broker. Database preparation or migrations for supported deployment targets operate on separately configured resources; they do not create those service instances. A project that requires a backend needs its own supported production architecture. Export source and the schema definition, provision the required services independently, configure production credentials, and validate migrations and application behavior there. Do not publish a development database endpoint or automatically copy test accounts, test data and secrets into production.

For operators running a development-only BuildWhat service, the application development database must remain separate from BuildWhat's own platform database. A production application database is not required until a supported production service actually needs it. An environment registration record does not mean a database instance has been deployed.

## Service isolation

| Service | Current boundary |
| --- | --- |
| PostgreSQL | The managed development provider is separate from the platform database. Project namespaces, access roles and scoped APIs isolate project data. This is not a dedicated database server for every project. |
| Files / MinIO | Project files use scoped object references and authorization through the application storage API. The platform's storage endpoint and administrator credentials are not handed to an app. A separate MinIO instance per project is not automatically created. |
| Redis | BuildWhat's internal cache, queues and rate-limit Redis are not an app service. There is no automatic per-project Redis provisioning. An app that requires Redis needs a separately provided service with suitable access isolation and a supported connection. |
| Kafka and other middleware | No automatic provisioning or operational support is implied. An externally supplied endpoint still requires a supported protocol, network access, credentials and integration. If that integration is unavailable, the requirement must remain explicitly unsupported rather than being represented as a working service. |

Dedicated instances are one isolation option. Separate databases, roles or provider-enforced namespaces can also work where the service supports them. Key prefixes alone are not Redis security isolation. For untrusted code, resource limits, network isolation, credential scope and lifecycle management must be enforced together.

## What Studio shows

While production hosting is unavailable, Data and Integrations show development environments. Production database maintenance, recovery and credentials are not offered as setup steps. Service-specific actions still depend on actual availability, project permissions and configured connections. Saving a secret does not deploy the corresponding service.