Deployment workflow

Help me prepare my existing project for PhotonSpark Webhost using the guide below. Ask for the project requirements and deployment choice when missing. Inspect existing files before editing, preserve behavior and data, and do not invent supported flags or deployment options. Keep credentials out of code and prompts. Explain dashboard settings and test production behavior. Publishing, DNS changes, and destructive actions need my authorization. Report what passed and what remains unverified.

# Deployment workflow

Prepare, publish, verify, and recover a customer release with clear evidence at each step.

Source: https://webhost.photonspark.com/docs/deployments

## Prepare the project

1. Choose Site, App, or SparkTunnel before changing the repository structure.
2. Inspect the existing project and preserve its APIs, authentication, and stored data.
3. Run the relevant build and production startup checks. Test the real application routes.
4. Review the diff and commit only the intended source, configuration, and lockfile changes. Keep generated caches and credentials out of Git.

```sh
git status --short
git diff --check
git diff
# Stage only the files you reviewed, then:
git commit -m "Prepare PhotonSpark deployment"
git push origin YOUR_BRANCH
```

## Publish through Webhost

For Git-connected resources, push the configured branch and let polling detect it, or request a deployment in the dashboard. Polling runs periodically; it is not an instant push webhook.

A build selects a source revision, produces artifacts, and creates a release. The running deployment can stay on its previous release if the new build fails. Inspect the build and runtime status separately.

For uploaded Sites, create a release from the intended publish files. For SparkTunnel, start and approve the connector, then activate the desired transport through its own workflow.

## Verify the public result

- Confirm the deployed revision matches the intended commit or uploaded release.
- Read build logs and check runtime startup and readiness.
- Open the public hostname and test HTTPS, assets, login, forms, API routes, and WebSockets or streaming if your application uses them.
- For Apps, test frontend-to-backend and database operations. A healthy frontend alone does not verify the backend.
- For SparkTunnel, test the local target and the public hostname independently.

## Recover deliberately

For an uploaded or Git-built Site, use its supported release rollback control to select a known working release. Check configuration and database compatibility before reverting an application.

Reverting code does not undo database migrations or restore deleted data. Use a reviewed database recovery procedure when data must change. Do not delete a Site, App, or connector to conceal a deployment failure.

- [Troubleshooting](https://webhost.photonspark.com/docs/troubleshooting)