gomodel migrate litellm does most of it.
1. Convert the config
Run a dry run first. It prints the migration report and the generated config, and writes nothing:--out writes three files and refuses to overwrite them unless you pass
--force:
os.environ/NAME references become ${NAME}, so the environment you already
run LiteLLM with keeps working. include: files are followed.
2. Review the report
ReadMIGRATION_REPORT.md before sending traffic. It has three lists:
- Review before switching traffic: things you must finish, such as guardrails, model access groups, or a Langfuse callback. GoModel guardrails are off until you configure them.
- Not migrated: settings with no GoModel equivalent, named one by one. Nothing is dropped silently.
- Behavior changes: settings that were converted but behave a little differently, such as routing strategies.
3. Run GoModel next to LiteLLM
Start GoModel with the generated files on another port. Add the variables listed under Environment in the report (the ones LiteLLM already read withos.environ/) to .env, creating it if the converter wrote none. GoModel
refuses to start while the variable server.master_key reads is unset. Then
send a few test requests with the models your clients use:
compose.yaml
.env with Compose env_file (or GoModel’s own .env loader when you
run the binary from that directory). docker run --env-file reads values
literally, so it would keep the quotes .env puts around values such as
inline JSON credentials. When you run the binary directly, a variable already
exported in your shell, such as OPENAI_API_KEY, wins over the same name in
.env.
GET /v1/models lists the same model names LiteLLM did. Then move clients
over one team at a time.
4. Import keys, teams, and budgets
LiteLLM keeps virtual keys, teams, users, organizations, and their budgets in its PostgreSQL database. The same command reads them when it knows the database:--database-url, else the config’s general_settings.database_url,
else DATABASE_URL. It only reads, inside a read-only transaction. Without a
database URL it converts the config alone.
Once GoModel runs with the converted config, import into it:
GOMODEL_MASTER_KEY, else the LiteLLM master
key, and needs https for a GoModel on another machine (--allow-http on a
trusted network, such as a Compose network). Without --gomodel-url it only
lists the import in the report.
Run it again while both gateways run side by side: it brings GoModel up to date
with LiteLLM. Keys get their current path, labels, allowed models, and expiry,
and keys LiteLLM has since blocked or expired are deactivated. Dashboard access
granted and keys deactivated in GoModel stay as they are. Rules for a path are
written before its keys; if one is rejected, those keys are held back and the
command exits with an error.
Each key keeps its sk-... value: LiteLLM stores only a SHA-256 hash of it,
and GoModel imports that hash,
so GoModel never handles the key itself. Everything else lands on a
user path:
Model access follows LiteLLM’s rules. A user’s model list binds that user’s
personal keys, not the team keys they hold, because only personal keys sit
under
/users/<user>. Model names resolve to the provider models behind them,
because GoModel checks the model a virtual model resolves to; if you later
point a virtual model at other models, update the allowed models that named it.
budget_duration maps to hourly, daily, weekly, or monthly (30d and
1mo both become monthly, which resets on calendar months), and other
durations to a fixed window. Not imported, and listed in the report:
- blocked or expired keys, and keys of blocked teams (deactivated if an earlier run imported them);
- budgets without
budget_duration: GoModel budgets reset every period; - spend: budgets start from zero, and the report shows LiteLLM’s current spend next to each one;
- team member budgets and per-model budgets and limits.
What changes for clients
How settings map
Provider names follow GoModel’s environment conventions: a deployment using
LiteLLM’s default key variable (
OPENAI_API_KEY) becomes provider openai,
one reading OPENAI_EU_API_KEY becomes openai-eu, and each Azure deployment
becomes its own provider, such as azure-gpt-4o-prod.
Providers GoModel does not support yet, such as Replicate or SageMaker, are
listed under Not migrated in the report.