Servbase does not treat every app type the same. Available actions depend on whether the app is file-based or runtime-based.
Supported app types
Deployment flow
At a high level:
- source is resolved from GitHub or uploaded files
- a single top-level folder may be auto-entered
- app-type-specific validation or build logic runs
- activation succeeds only after runtime or output validation passes
Action availability by app type
Static / HTML and PHP are not documented as rebuildable runtime app types. After the initial deployment, ongoing file-level changes are expected to use your workspace or file-management workflow.
Rebuild vs restart
Rebuild
Rebuild re-runs the build or runtime preparation flow for the app.
There are two customer-facing rebuild paths:
- Rebuild from workspace — uses the current files already in the Servbase workspace. This is the normal path when the app was created from ZIP upload or folder upload, and it is also useful after editing files in the Servbase code editor.
- Rebuild from GitHub — available when the app is connected to a GitHub repository. This path re-clones the repository and rebuilds from the selected GitHub source.
Which rebuild source to use
Use workspace when:
- the app was uploaded from ZIP or folder
- you changed files directly in the Servbase workspace
- you want to rebuild the currently stored workspace contents
Use GitHub when:
- the app is connected to GitHub
- the latest intended changes are in the repository, not just in the workspace
- you want Servbase to re-clone and rebuild from the repository source
Restart
Restart only restarts the already-provisioned runtime service. It does not pull new source code and does not rebuild the app.
Restart only applies when the runtime service exists and the latest deployment is healthy enough to restart.
Deployment blocking conditions
Some actions are blocked when:
- the app type does not support the action
- the app is paused for overdue billing
- the required source or runtime state is missing
