What every project gets
No feature has asked for more yet, so nothing more is created.
- Static output, served from the edge
- No database provisioned
- No permanent Node process kept running
- No backend project created
HOSTINGSURGE BACKEND
Backend on demand. Only for what actually needs it.
Generate a website and it deploys as static output by default. A backend, a database or a permanent process appears only when a feature you asked for genuinely requires one.
In development: backend provisioning, object storage and backup restore are sandbox-stage. No backend project, bucket or restore has been verified yet.
Static first, backend on demand
Provisioning a database or a permanent process because a model generated a website is not a trade-off this platform makes. If the result can be served statically, it is served statically.
What makes a backend appear
One of these has to be genuinely needed before anything is provisioned:
- Users and login
- Persistent business records
- Realtime updates
- Private file uploads
- Server-side secrets
- Scheduled secure jobs
- Private APIs
In development: the provider adapter and per-project provisioning are the next stage of the platform. Today the rule above is a design commitment, and no backend project has been provisioned for a customer.
What you see, and nothing else
A normal customer is never required to open the vendor console behind the product. Your project shows Backend, Users, Authentication, Database, Storage, Functions and API — with toggles that decide which of them exist here at all.
Backend
One isolated backend project mapped to your Hostingsurge project, created only when a feature asks for it.
Users
Accounts that belong to your application, not to a shared login pool.
Authentication
Sign-in handled by your project, with the flows you enable rather than flows imposed on you.
Database
Records for your application in a project-scoped instance — never a shared bucket of tables.
Storage
Private uploads and files, with credentials kept separate from backups and from the platform itself.
Functions
Server-side code that runs when a request needs it, instead of a process that runs all the time.
API
Your application talks to its own backend project through project credentials — nothing broader.
Feature toggles decide what a project carries:
AuthenticationDatabaseStorageRealtimeFunctions
Sandbox stage: backend provisioning and object storage are in development. The views above describe what a customer will see — no backend project or storage bucket exists yet, and none of it is billed as delivered.
Credentials that stay inside your project
An isolated backend project is created per application and mapped to the Hostingsurge project it belongs to. Isolation is the reason the rest of this works at all.
Designed guarantees
These are the rules the adapter is being built to enforce.
- One isolated backend project per application, mapped to its Hostingsurge project
- Project-scoped credentials created for that project alone
- Secret references stored securely, never inlined into your code
- Platform admin credentials never placed in customer code
- Your application receives only the client credentials it needs
- Every project is scoped to its organization and brand
Credential model
- ScopePer project and organization
- Delivered to the appProject client credentials
- Platform admin keysNever in customer code
- SecretsStored as references
- Object storageSeparate from the backup target
- Root credentialsNot exposed to applications
Designed, not yet exercised: the provider adapter is in development and no customer backend project exists yet, so this credential model is specified rather than proven in production.
Storage is several separate things
Source code, deployment files, database storage, customer uploads and backups are modelled as separate concepts — different lifetimes, different credentials, different risk.
Kept apart by design
Customer uploads are the one part that grows on its own, so they get the strictest separation.
- Dynamic uploads use S3-compatible object storage when it is enabled
- Storage credentials are separate from the backup target
- Master object-storage credentials are never exposed to your application
- Short-lived, project-scoped operations are used where possible
Storage concepts
- Source codeKept in versions
- Deployment filesPer deployment, replaceable
- Database storageWith the database project
- Customer uploadsObject storage when enabled
- BackupsSeparate target and credentials
Metering, and its current status: usage metering is designed to record database storage, object storage, AI cost, build minutes, CPU and RAM allocation and runtime from day one — including usage a plan calls included. No real object-storage connection has been made or verified.
Backups by project type
What counts as a complete backup depends on what the project is. A backup is not considered healthy until a restore has been tested.
| Project type | What a backup covers |
|---|---|
| Static project | Source, configuration and deployment metadata |
| Database | Scheduled dumps or snapshots |
| WordPress | Database, wp-content and critical configuration |
| Agent | Persistent workspace and configuration |
Not verified yet: backups are designed to live outside primary compute, and no real backup or restore has been executed or verified. Treat every policy above as specified, not proven.
Questions worth asking
Straight answers about when a backend appears — and when it deliberately does not.
Will my project get a database automatically?
No. Backend on demand means a database is provisioned only when a feature requires persistent records. A generated website that can be served statically gets no database at all.
What exactly makes a backend appear?
One of the triggers: users and login, persistent business records, realtime, private file uploads, server-side secrets, scheduled secure jobs or private APIs. Nothing else.
Do I need a backend for a brochure site?
No. Static output is the default and the honest answer for a site that only presents information. A backend can be added later without rebuilding the project.
Can I bring my own database?
Database apps for PostgreSQL, MySQL/MariaDB and Redis exist in the app catalog, and object storage is offered the same way. Platform-managed database provisioning is in development. Supabase is treated as a migration source, not as the default backend for new projects.
Do I ever have to open a vendor console?
No. The backend engine behind the product is not something a normal customer is required to open. You work with Backend, Users, Authentication, Database, Storage, Functions and API inside your own project.
Static by default. Real when needed.
Your project gets the infrastructure its features require — and none of the terminology that usually comes with running it.