Ollama and Fly.io Sprites: Run AI Agents Safely with Cloud Models via the Ollama Connector

Ollama Cloud can now be used from inside Fly.io Sprites, the sandboxed Linux virtual machines Fly.io builds for running AI agents. The integration ships as a new Ollama Connector that stores your Ollama API key at the Fly.io organization level and injects it at a gateway, so an agent running inside a sandbox never holds the credential itself.

The announcement matters because it separates two things that agent deployments usually conflate: the ability to call a frontier model, and the ability to run untrusted, model-generated commands safely. Sprites provide the isolated execution environment; the Ollama Connector provides scoped, key-free access to Ollama's cloud models.

What Fly.io Sprites are

A Sprite is a sandbox from Fly.io. Each Sprite is a full Linux virtual machine with its own disk that persists between sessions.

Claude Code, Codex and Gemini CLI are supported out of the box, which lets agents run commands inside a sandbox rather than on a developer's machine.

Which Ollama models are available

With the Ollama Connector, Sprites can call Ollama's cloud models. The announcement names three examples: kimi-k3, glm-5.3, and deepseek-v4.1-flash.

How the Ollama Connector protects the API key

You add your Ollama API key to your Fly.io organization, and Fly.io encrypts it and never returns it through the API.

When code inside a Sprite calls Ollama, the request goes through a Fly.io gateway. The gateway checks which Sprite is calling and adds your key to the request. The Sprite itself only knows a gateway URL and a connection ID.

The security properties Ollama and Fly.io state for this design are:

  • An agent in a Sprite cannot leak your key.
  • New connectors block every Sprite by default. You choose which ones get access: by label, by name prefix, or all of them.
  • Calls only work from inside a Sprite.

Setup: adding the Ollama connector to a Fly.io organization

You need an Ollama API key and at least one Sprite.

  1. In the Fly.io dashboard, open Sprites, then Connectors, and add an Ollama connector with your API key.
  2. Under Access Configuration, choose which Sprites can use it and save.
  3. Click Test reachability next to a Sprite to check that it can reach Ollama.

Calling Ollama from inside a Sprite with curl

The connector page shows the request command with your connection ID filled in. There is no Authorization header because the gateway adds your key.

curl "https://api.sprites.dev/v1/gateway/ollama/<connection_id>/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Hello!"}]}'

Calling Ollama from inside a Sprite with Python

Any OpenAI SDK works. Set base_url to the gateway and use any value for api_key.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.sprites.dev/v1/gateway/ollama/<connection_id>/v1",
    api_key="unused",
)

response = client.chat.completions.create(
    model="glm-5.3",
    messages=[{"role": "user", "content": "Why is the sky blue?"}],
)
print(response.choices[0].message.content)

Ollama's native /api/* routes also work through the gateway, so existing Ollama client code does not need to be rewritten to use the OpenAI-compatible path.

Coding agents get Ollama support automatically

Fly.io Sprites come with a skill that tells Claude Code, Cursor, Codex and Gemini CLI about Ollama. If the Sprite has access to the connector, the agent can use Ollama models without any additional setup.

Example use case: multi-model fuzzing

Fly.io publishes a guide that uses several models together for fuzzing. A small model such as nemotron-3-nano:30b writes malformed inputs, a Sprite runs those inputs against your program, and a larger model such as kimi-k3 examines the resulting crashes. Switching between the two roles requires only changing the model field in the request.

What this integration is for

The Ollama Connector targets the case where an agent needs both a capable cloud model and a place to execute code that may be hostile or simply wrong. The sandbox supplies the isolation and the persistent disk; the gateway supplies the credential and the access policy. Neither the agent nor the code it runs ever sees the Ollama API key.

Sources