# Choose build and runtime settings for your framework

GD detects project files and proposes settings. Detection is a starting point, not a reason to ignore the project's own setup instructions. The same programming language can produce a static website, a web server or a background worker, and each needs a different way to run.

## Before you start

- Find the project's README, dependency manifest and example environment file. Decide which folder is the application root. Use the runtime versions offered by GD that the project supports. Keep database credentials and other secrets outside public code and browser-visible settings.

## Node.js applications, including AdonisJS

1. Check package.json and its scripts. Select the package manager matching the committed lockfile; avoid mixing lockfiles from several managers.
2. Set install and build commands from the project instructions. TypeScript generally needs compilation before the production server starts.
3. For AdonisJS, confirm the production build entry point, required application key, host, port and environment settings. A project containing React or Vite assets can still be an Adonis backend; do not deploy only its frontend folder by mistake.
4. For Next.js, React Router, Remix, Nuxt or SvelteKit, check whether this project is built as a server application or a static export. The correct output and start settings depend on that choice and its adapter.
5. For Express, Fastify or NestJS, confirm the server entry point and bind to a reachable interface and the configured port.
6. Deploy, inspect startup logs and test a server-side route. For a database-backed app, test a query through the app too.

## PHP applications

1. Check composer.json, PHP version constraints and required extensions. A database driver such as PDO MySQL is separate from the database server itself.
2. Confirm the public document root. Frameworks often use public, web or webroot; serving the entire repository can expose private files.
3. For Laravel or another framework with migrations, review the migration command and database destination. Back up existing data before schema changes.
4. Configure required application keys and environment values. Keep keys stable where changing them would invalidate encrypted data or sessions.
5. Identify persistent upload/storage folders. A new deployment must not discard user uploads that the app expects to retain.
6. Configure queue workers or scheduled commands only when the app uses them. A web server being healthy does not prove its background jobs are running.

## WordPress and existing PHP sites

1. Confirm the database connection and the site's expected address before moving it.
2. Include required themes, plugins and uploaded content using the supported source and persistent-storage workflow.
3. Test administration, media URLs and a representative form after deployment.
4. If the old address appears in content, review the application's supported URL-change process. Do not blindly replace text in a database export; some stored formats need specialised handling.

## Python applications, including Ferro

1. Confirm the dependency file and Python version. Native packages may require compatible wheels or build dependencies.
2. Identify the application's import path and its required production server. Flask and Django configurations are not interchangeable with ASGI applications such as FastAPI.
3. For Ferro, review the detected Ferro server command and installed package compatibility. GD's catalogue identifies this support as alpha; validate the specific app before using it for critical traffic.
4. Supply the required host/port and environment values. A development server or loopback-only binding may not be reachable through hosting ingress.
5. Review worker and thread settings. A worker is a separate process; threads allow concurrency within a process. Both consume resources, and extra concurrency does not increase workspace CPU or memory.
6. Begin with the detected configuration, measure response times and memory, then change one concurrency setting at a time. Check the app's database pool as well: more processes can open more connections.

## Ruby applications

1. Check the Ruby version and Gemfile.lock, then use the project's dependency and build instructions.
2. Confirm its production server, port and required environment values.
3. For Rails, review database preparation/migrations and asset compilation separately. Back up existing data before changing its schema.
4. Configure required job workers, schedules and persistent uploads, then test them independently of the homepage.

## Static HTML and frontend builds

1. Choose the static mode only when the finished application can be served as files without its own backend process.
2. For plain HTML, identify the folder containing index.html. For a frontend build, identify the actual generated output folder.
3. Configure any required client-side routing fallback and test a nested URL directly, not just through navigation from the homepage.
4. Check API URLs compiled into the frontend. Changing a build-time variable usually requires another build.
5. Never put database passwords or server API secrets into frontend variables. Visitors can inspect the delivered JavaScript.

## If something does not work

- Wrong framework detected: inspect Detection details, project directory and dependency files before choosing an override.

- Build cannot find a dependency: check the lockfile, runtime version and whether build-time development dependencies were incorrectly omitted.

- Build succeeds but the app is unavailable: compare the start entry point, host and port with the built output.

- Uploads disappear after redeployment: check the persistent-storage mapping and the path the app actually writes to.

- More workers make the app slower: check CPU, memory and database connections; reduce concurrency before increasing it again.

## Expected result

The selected settings match this repository's deployment model, the running process is reachable, and database, uploads and background work are tested where applicable. Framework detection alone is not a production acceptance test.

Open the relevant page, then confirm the workspace or administrative context before making changes.
- [Open Deploy Application](/hosting/applications/create)

## Related guides and references

For signed-in procedures, open Help in your workspace and search by the task name. Administrative guides require the internal-documentation permission.

- [Public Help Centre](/docs)

- [Deploy your first application](/docs/getting-started/deploy-your-first-application)

- [Deployment status and recovery](/docs/applications/deployment-status-and-recovery)

Source: https://ghostdeploy.com/docs/applications/choose-framework-settings