Guides

Step-by-step guides that take a framework, an AI agent or an AI tool from an empty folder to a running deployment on Sevalla, with Ingot, a Dockerfile or the API.

A guide takes one framework, AI agent or AI tool from an empty folder to a running deployment on Sevalla: it creates the project, prepares it, deploys it, and shows how to check that it works. Each guide builds the project with Ingot, Sevalla’s builder, and also gives a production Dockerfile for it; guides for packaged tools deploy the vendor’s official Docker image. Sites that build to static files can also be a free static site; Hugo, Jekyll and MkDocs, which Ingot doesn’t build, use a static site or a Dockerfile. Swift, Dart and Scala projects build from a Dockerfile, because Ingot doesn’t build them.

Every guide ends with the same deployment as API calls, with the matching CLI command and MCP tool for each step, so an AI agent can follow it without the dashboard.

AI applications

AI overview

How AI applications run on Sevalla: streaming, long agent runs, private services, state and security.

MCP servers

Remote MCP servers in TypeScript and Python that Claude Code, Cursor and the model APIs call.

Agents

The Claude Agent SDK, the OpenAI Agents SDK, LangGraph and Mastra, with tools and memory.

Claude Code and swarms

Claude Code in the cloud from the web terminal, and agents that review each other’s pull requests.

Chat and retrieval

A streaming chatbot, RAG with pgvector, hybrid search, and the Qdrant vector database.

Models and tools

Ollama, LiteLLM, OpenRouter, Open WebUI, LibreChat, AnythingLLM, n8n, Langflow, Flowise, Dify and Langfuse.

Languages

JavaScript

Node.js, Bun and Deno: Next.js, Nuxt, Astro, SvelteKit, Angular, Express, NestJS, Hono, Medusa, Playwright and more.

Python

Django, FastAPI and Flask with databases, caching and Celery, plus Wagtail, Litestar, Dash, Streamlit and Gradio.

PHP

Laravel with queues, Horizon, Octane and Reverb, plus Statamic, Symfony, CodeIgniter, Drupal and WordPress, served by FrankenPHP.

Ruby

Rails with background jobs, Active Storage and caching, Hanami, and Sinatra.

Go

The standard library’s net/http, chi, Gin, Echo, Fiber, and gRPC services.

Rust

Axum, Actix Web, Rocket, Leptos with server-side rendering, and Loco with PostgreSQL.

Java, Kotlin and Scala

Spring Boot, Quarkus, Micronaut, Ktor, and Play in Scala.

.NET

ASP.NET Core and Blazor.

Elixir

Phoenix with Ecto, LiveView and Mix releases.

Gleam

Wisp on Mist, on the Erlang runtime.

Swift

Vapor with Fluent and PostgreSQL, built from a Dockerfile.

Dart

Dart Frog, compiled ahead of time in a Dockerfile.

Static site generators: Docusaurus, Eleventy, Gatsby, Hugo, Jekyll, MkDocs and VitePress.

Migrate from another platform

Each migration guide maps the other platform’s features to Sevalla’s, moves the data, files and environment variables, and switches the domain, tested with a real app on that platform.

Heroku

Move a Heroku app’s Procfile processes, config vars, Postgres and Redis to Sevalla.

Render

Move Render web services, private services, workers, cron jobs, disks, Postgres and Key Value, with the data, files and domains.

Railway

Move a Railway project’s services, PostgreSQL, Redis and volumes to one application with processes, databases and a disk, built with Railpack or Ingot.

Vercel

Move a Next.js project from Vercel: Postgres, Blob files and Cron Jobs, with a shared ISR cache across instances.

Fly.io

Move a Fly.io app’s process groups, release command, volume, secrets and Postgres to one application with a disk and a database.

Netlify

Move a Netlify site to a static site and its Functions to an application: rules, build variables, deploy previews, form submissions and domains.

DigitalOcean App Platform

Move an App Platform app’s services, workers, jobs, static sites and managed PostgreSQL, mapping its app spec, bindable variables and routes.

How a guide is laid out

Every framework guide has the same parts, so you can skip to the one you need:

Section	What it covers
At a glance	What the guide deploys (build, start command, port, processes, services, size) and every environment variable it needs
Before you begin	The accounts and local tools the guide needs, with their versions
Create the project	The framework’s own scaffolding command and the code the guide adds
Prepare the project for Sevalla	The language version to pin, the lock file to commit, and what Ingot detects
Deploy to Sevalla	Creating the application in the dashboard and deploying it with Ingot
Verify the deployment	The build plan you see in the build log, and the commands that check the application, with their exact output
Deploy with a Dockerfile	A production Dockerfile and .dockerignore for the project, and switching the application’s build strategy to Dockerfile
Troubleshoot	The errors you can meet, quoted exactly, with their cause and fix
Deploy with the API	The same deployment as ordered API calls, with the CLI command and MCP tool for each step

Guides for frameworks that need more (a database, a worker, a migration job, object storage) add a section for each, in the order you set them up. To find an error you got, search Error messages; for sizes, timeouts and other limits, see Limits.

Ingot or a Dockerfile

Both build the same kind of image, and the application runs the same way: the web process listens on the port in the PORT environment variable, 8080 by default, and every process runs from the same image.

	Ingot	Dockerfile
What you write	Nothing for most projects. A pinned language version, and an ingot.json file when you need to change what Ingot detects.	A Dockerfile and a .dockerignore that you maintain
How it picks versions	From the project’s own files, such as engines.node in package.json or .python-version	The base images you choose in FROM
Updates	A new Ingot release brings new language releases and fixes to the generated Dockerfile	You update the base images and the file yourself
See the result	The build plan in the build log, and the generated Dockerfile on the deployment’s Dockerfile tab	Your file, on the deployment’s Dockerfile tab
Choose it	The default for new applications from Git	On the application’s Settings tab, with Update build strategy

Start with Ingot. Switch to a Dockerfile when the image needs something Ingot doesn’t install, such as a system package or a different base image, or when you already maintain one. See Build strategies.