Install
Add an app when a feature needs it — not before.
App store
One-click apps. Only when you ask.
Databases, CMS, search, automation and AI tooling for a project — added from the App Store, reviewed before they appear and installed only on your request.
In development — the App Store is early access. No app is installable today, and nothing is installed without an explicit request from you.
Grouped by what they do
Categories cover what a project usually needs next. Nothing is installed upfront: an app appears in a project only after you ask for it.
CMSDatabasesAutomationAIAnalyticsSearchDeveloper toolsBusiness toolsStorageMonitoringOther
A curated catalogue, not a container dump
Every item is an app entry with a Hostingsurge name and a fixed contract: what it gives you, which category it belongs to, how risky it is and how much it is supported. The engine behind it stays invisible.
| App | What it gives you | Category |
|---|---|---|
| Backend | App backend: accounts, database and storage | Developer tools |
| PostgreSQL | Relational database for serious workloads | Databases |
| MySQL / MariaDB | Relational database for classic web apps | Databases |
| Cache | In-memory cache that makes repeated reads fast | Databases |
| WordPress | Managed WordPress with the Hostingsurge Connector | CMS |
| Headless CMS | Structured, editorial content served through an API | CMS |
| Analytics | Privacy-friendly traffic insights for your site | Analytics |
| Search | Fast, typo-tolerant search for content and products | Search |
| Vector database | Embedding storage for AI features and retrieval | AI |
| Automation | Visual workflows between your apps and services | Automation |
| AI workflows | Chains and agent flows over your own models and data | AI |
| Internal tools | Admin panels and dashboards on top of your data | Business tools |
| AI agent | A private, bounded agent runtime for your automations | AI |
| Forms | Forms with storage, notifications and spam handling | Business tools |
| Git | Repositories for your projects — normally internal | Developer tools |
| Custom Docker | Bring your own container image (premium and developer capability) | Developer tools |
Everything is presented under Hostingsurge names, running on industry-standard engines. Which engine sits behind an item is not part of the customer interface: you never manage a vendor dashboard, a deployment control plane or container terms.
Every item is reviewed before it appears
The catalogue has one rule: nothing shows up in the App Store until it has passed review and carries a complete contract. Each entry records:
- Upstream, license and app version
- Template version and upgrade strategy
- Risk level and support level
- Minimum resources and default resource caps
- Persistent paths and backup strategy
- Health check, customer visibility and brand availability
Lifecycle — from draft to approved. Until approval an app stays invisible to customers:
DraftLicense reviewSecurity reviewApprovedDeprecatedBlocked
In development. The App Store is specified, not shipped: the catalogue with these fields, the approved-only visibility rule and install/update/restart/backup/logs/uninstall through the deployment provider are work item C3 in the platform’s status document. No app is installable today, and nothing is installed without an explicit customer request.
What you can do with an installed app
Once an app is in a project it behaves like the rest of the platform: the same dashboard, the same concepts, no vendor panel anywhere. Per installed app:
Update available
The service tells you a newer version is ready instead of updating itself.
Restart
Restart after a change, from the same place where you read the logs.
Backup
Take a backup before a risky step, with a restore behind it.
Logs
Read the service’s own logs as plain text, without a jump host.
Open
Reach the app the way it was meant to be used — no vendor account required.
Uninstall
Remove the app and its resources again. Nothing lingers as an orphan.
Updates are managed, not mass-applied
The installed template version is tracked per service, and an update scanner reports what changed upstream. A newer release is never pushed onto every service at once.
Updates available
A newer template version exists for a service you run. You decide when it is applied.
Security update
A fix that matters, flagged as the highest priority — still through a rollout, never a blind swap.
Breaking update
A change that needs attention before it is applied, reviewed with you instead of rolled out silently.
Governance principles
- Upstream supportReviewed apps only
- Generic backend appNot offered — Backend is the experience
- SupabaseImport and compatibility only
- Headless CMSWhen content is structured
- Static sitesNo CMS forced in
Rollout policy
- Canary update first, then a staged rollout
- Rollback available when a rollout does not behave
- No mass upgrade of customer services without policy
- Template versions tracked per service, not per platform
Starting a container template is not the same as supporting an upstream app. An app is offered because it has been reviewed and supported — never merely because it can be started.
App Store questions
How the catalogue behaves — including what is not available yet.
Is anything installed automatically?
No. Nothing is installed upfront in a project, and nothing is added without an explicit request. A project gets the infrastructure and the apps that a feature actually needs.
What happens when an upstream release has a security fix?
The update scanner reports it for the services that use it. Rollouts go canary first and then in stages, with rollback available — a customer service is never mass-upgraded without policy.
Do I need to understand Docker or containers?
No. You work with app names, resources and buttons: Install, Update, Restart, Backup, Logs, Open, Uninstall. The deployment control plane, vendor dashboards and container terms stay on our side.
Can I run my own container image?
Custom Docker is a premium and developer capability in the catalogue. It goes through the same review as everything else, and it is not a way around the platform’s isolation rules.
Why do some apps take longer to appear?
Because they are reviewed first: license review and security review happen before an app reaches the approved state, and only approved apps with brand availability are visible to customers.
Is the App Store live today?
No. It is in development and no app is installable yet. The catalogue, the review fields, the lifecycle and the per-app operations on this page describe how it is being built.
Add what the project needs. Nothing more.
The App Store is built so a project gets the infrastructure and the apps a feature actually requires — installed on request, reviewed before they appear, and removable again.