Bring your code.Give it a place to run.

Start with what your app actually needs.

A hosting decision starts with the thing you are shipping. A generated website needs a place for its files. A server-rendered application also needs a compatible runtime. A product with customer records needs a database and a deliberate way to grant access. These are different questions, even when the source lives in the same repository.

Fortly brings those parts into one project. Your source becomes a release, and the project keeps its address, data and files as you ship updates. Start with the workload below, then use the linked deployment guide to check the exact framework and output requirements.

You do not need to buy a separate database product just to try an idea. A project can create its own PostgreSQL database when you use it. File storage and the Data API are part of the workspace too; their account allowances depend on your plan.

One release path, whichever way you start.

Connect a GitHub repository when you want a selected branch to deploy on push. Choose an archive when the project is on your laptop or built somewhere else. The console accepts ZIP and tar.gz files and lets you review the detected framework, variables and source before you confirm. Both routes lead into the same release view.

1. Choose the source. Use New project for a fresh app, or Deploy application / New deployment from an existing project’s Overview.
2. Review the settings. Check the branch or archive root, framework, package manager and variables. Server applications need a supported build path.
3. Follow the release. Source, build and publication have their own status and output. Open the app when the release is live.

An accepted build is not the same as a published application. Keep the release panel open to follow it, or return later: the work continues when you leave the page. A failed attempt stays in history. If an earlier release was already serving visitors, it keeps serving while you investigate.

The application is only the beginning.

Once your app is live, the next task is usually a data task. Open Database to create tables, edit records, inspect relationships or run SQL. Use API & Access to review the operations a browser-facing key can perform. API access begins closed; creating a table does not automatically publish its rows.

Use Storage for uploaded assets and Domains for your own hostname. Use Observability for requests, response times and application logs. Each workspace belongs to the project you are already managing, so the source, release and resource you are investigating stay connected.

A Worker with a provisioned project database can use its injected DATABASE_URL with supported drivers, opening connections inside requests. Scoped HTTPS Data API roles provide another path. The PostgreSQL page explains the distinction and links to both client and server access patterns.

Make the fit explicit before you move.

Fortly’s server builds produce Workers. It is not a general-purpose VPS, and a successful npm install does not make every operating-system dependency available at runtime. If your app depends on native executables, a background daemon or provider-specific bindings, review that dependency before committing to a migration. The build compatibility reference is the authoritative list.

Begin with a free project to validate the workflow. The published plans describe project counts and shared account capacity. Extra capacity and production suitability are separate decisions from whether the first page builds.

A repository can hold more than one application.

Each current Fortly project publishes one application release at a time. GitHub linking selects a repo and branch; multiple detected apps need an unambiguous source rather than an assumed per-service folder. Selecting an archive subtree also removes outside dependencies. Plan the source layout before connecting a shared workspace.