Choose build and runtime settings for your framework

Node.js applications, including AdonisJS

1. 1Check package.json and its scripts. Select the package manager matching the committed lockfile; avoid mixing lockfiles from several managers.
2. 2Set install and build commands from the project instructions. TypeScript generally needs compilation before the production server starts.
3. 3For 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. 4For 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. 5For Express, Fastify or NestJS, confirm the server entry point and bind to a reachable interface and the configured port.
6. 6Deploy, inspect startup logs and test a server-side route. For a database-backed app, test a query through the app too.

PHP applications

1. 1Check composer.json, PHP version constraints and required extensions. A database driver such as PDO MySQL is separate from the database server itself.
2. 2Confirm the public document root. Frameworks often use public, web or webroot; serving the entire repository can expose private files.
3. 3For Laravel or another framework with migrations, review the migration command and database destination. Back up existing data before schema changes.
4. 4Configure required application keys and environment values. Keep keys stable where changing them would invalidate encrypted data or sessions.
5. 5Identify persistent upload/storage folders. A new deployment must not discard user uploads that the app expects to retain.
6. 6Configure 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. 1Confirm the database connection and the site's expected address before moving it.
2. 2Include required themes, plugins and uploaded content using the supported source and persistent-storage workflow.
3. 3Test administration, media URLs and a representative form after deployment.
4. 4If 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. 1Confirm the dependency file and Python version. Native packages may require compatible wheels or build dependencies.
2. 2Identify the application's import path and its required production server. Flask and Django configurations are not interchangeable with ASGI applications such as FastAPI.
3. 3For 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. 4Supply the required host/port and environment values. A development server or loopback-only binding may not be reachable through hosting ingress.
5. 5Review 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. 6Begin 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. 1Check the Ruby version and Gemfile.lock, then use the project's dependency and build instructions.
2. 2Confirm its production server, port and required environment values.
3. 3For Rails, review database preparation/migrations and asset compilation separately. Back up existing data before changing its schema.
4. 4Configure required job workers, schedules and persistent uploads, then test them independently of the homepage.

Static HTML and frontend builds

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

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.