Build the thing.Know the next step.

Find the guide that matches your task.

The first hosting question is often smaller than “which platform is best?” It might be how to deploy a repo, why a build failed, or how a frontend should read a table. These guides begin at that task and carry the context forward: source, runtime, identity, release and the result a visitor should see.

8 starting points

No match yet. Try “deploy”, “static” or “database”, or open the full documentation.

A few good paths through the product.

A first idea, from your laptop

Begin with a page or small app you can already run locally. Decide whether its output is static or needs a server. Use the matching hosting page to check the runtime, then upload an archive or connect a repository. A successful build is a milestone; opening the public URL and exercising the intended route is the verification.

An existing application, moving hosts

Inventory more than the source files. Record the framework, build command, output, environment values, database access, file storage and provider-specific services. Match each dependency to a documented Fortly path. A new frontend build cannot recreate an external database or a provider-specific backend simply because the original app once deployed successfully.

A live app, with a change to ship

Keep the current release in view. Review the new source and variables, follow the selected release’s build output, and verify the published app with a real route and data request. If a build fails, read its first meaningful error. If a build succeeds but a request fails, switch to runtime and access diagnostics rather than repeatedly changing the build.

Use the right depth of explanation.

Start with a guide to decide and complete a task. Open the linked documentation when you need the exact contract: request fields, response shapes, current limits, framework conditions and the consequences of an operation.

For a Next.js application, check build variables before compilation and data access before testing a route. For a failed build, follow the selected release output before inspecting runtime logs. For a database, review the actual grant and export behavior before planning production use. Each path below connects the decision to its implementation reference.

What a useful guide should leave you with.

After a deployment guide, you should know what source was deployed, which branch or archive it came from, where its output is recorded and how to verify the public application. After a data guide, you should know who the caller is and which operations the key or identity can perform. After a troubleshooting guide, you should have a specific next action, not another unexplained retry.

Examples here use clearly labelled sample projects and records. They do not create projects or change your account. Commands that need your project name or token say so; browser-facing examples use publishable access only when the required grants have been reviewed. Use the current documentation for the precise limits before planning a production workload.

If the guide gets you to a question about your own project, contact the Fortly team with the project URL, the relevant release and the first meaningful error. That is enough context to start a useful conversation without reproducing your entire application in a message.