Guides - Sevalla docs

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, which Ingot doesn’t build, uses a static site or a Dockerfile. 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, and the Qdrant vector database.

Models and tools

Ollama, LiteLLM, OpenRouter, Open WebUI, n8n, Langflow and Langfuse.

Languages

JavaScript

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

Python

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

PHP

Laravel with queues, object storage and caching, Symfony and WordPress, served by FrankenPHP.

Ruby

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

Go

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

Rust

Axum, Actix Web and Rocket.

Java and Kotlin

Spring Boot, Quarkus, Micronaut and Ktor.

.NET

ASP.NET Core and Blazor.

Elixir

Phoenix with Ecto, LiveView and Mix releases.

Static site generators: Docusaurus and Hugo. Moving an application from another platform: Migrate from Heroku.

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.

​AI applications