Why security teams want Shuffle AI agents with self-hosted LLMs
Security operations and incident response teams often want AI-assisted triage inside Shuffle, but they cannot send alert data, IP addresses or user details to an external model provider. A Shuffle AI agent can use a model served inside your own network through Ollama or vLLM, and this page explains how that is set up and what it trades off. The first decision is where the model runs, because that answers who sees prompts, who controls the endpoint and who operates the hardware behind it. Each choice moves responsibility from a provider to your team, so security, platform and data protection leads should make that decision together.
Separate what is documented from what you must verify before you commit. Shuffle's public documentation covers the platform architecture, the app runtime and pricing. The server side includes a frontend, a Go backend API on port 5001 and an OpenSearch document database. Orborus polls the backend for jobs, starts a worker for each workflow execution, and that worker starts app containers. The exact agent and MCP configuration screens can differ between releases, so confirm them against the Shuffle version you run and read the release notes for the tag you pin before you design around any specific setting.
Shuffle is licensed under AGPL-3.0 and documents four deployment architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus, and Kubernetes with Helm charts. These options matter here as context for control. In a self-hosted layout, your team controls the runtime where agent steps execute. In the hybrid layout, the local Orborus needs no inbound firewall ports, but the workflow control plane sits in Shuffle Cloud. Confirm with Shuffle which data leaves your network and where any agent or model calls are routed before you approve the design.
Ollama and vLLM ask different things of your team. Ollama is an MIT-licensed runtime with a REST API on port 11434 that offers OpenAI compatibility. It binds to 127.0.0.1 by default, and its local API does not require authentication, so exposing it to Shuffle usually means placing a proxy with access control in front of it. Ollama states that local runs do not expose your prompts to it, and setting OLLAMA_NO_CLOUD=1 turns off cloud features. vLLM is Apache-2.0 and its vllm serve command exposes OpenAI-compatible endpoints. Its --api-key option does not protect /metrics or /health, and the vLLM security docs recommend a reverse proxy that allowlists only the endpoints users need. Multi-node traffic is insecure by default and must sit on an isolated network.
Before build, decide three things: the model host and accelerator capacity, the reverse proxy allowlist, and how long agent decisions and traces are retained. Ask the Shuffle team to confirm which agent and MCP settings your version exposes. Ask for a quote that separates hardware, Ollama or vLLM operation, Shuffle configuration and testing. Shuffle's pricing counts app runs, so confirm whether any inference routed through Shuffle Cloud is billed separately. vLLM has no paid edition, so its cost comes from accelerator capacity, surrounding infrastructure and the people who operate it.
Which model source fits your alert data and operating model
This table compares three model sources for Shuffle AI agents across where prompts are processed, who runs the model, the authentication each option documents, its cost model and its main operational risk. Read each column as one operating choice, and confirm the Shuffle Cloud AI usage cost with Shuffle before you compare budgets. The main takeaway is that both self-hosted options keep alert data inside your network, but they move endpoint security and day-to-day operations to your team.
| Factor | Self-hosted Ollama | Self-hosted vLLM | Shuffle Cloud credits |
|---|---|---|---|
| Where prompts are processed | On the host running Ollama when run locally, which does not send prompts or data | On the vLLM server inside your infrastructure, under your network controls | Outside your network, on Shuffle Cloud, with inference billed to credits |
| Who runs the model | Your team, on hardware you provision, patch and monitor | Your team, including accelerator capacity, scaling, upgrades and monitoring | Shuffle operates the model service; confirm model choice and availability with Shuffle |
| Authentication as documented | The local API on port 11434 needs no authentication by default and binds to 127.0.0.1 | The --api-key option covers /v1 endpoints only, so add a reverse proxy that allowlists user endpoints | Access is tied to your Shuffle account; confirm the authentication details with Shuffle |
| Cost model | Running models on your own hardware is unlimited per Ollama's pricing page; your costs are hardware and staff time | Apache-2.0 with no paid edition; your costs are accelerator capacity, infrastructure and operators | Usage is tied to app runs, meaning executed actions; confirm the AI usage cost with Shuffle |
| Main operational risk | Exposing the API beyond localhost without authentication if the bind address or proxy is changed | Multi-node traffic is unauthenticated and unencrypted by default, so nodes need an isolated network | Costs and throughput grow with alert volume; confirm credit limits and app run impact with Shuffle |
How a Shuffle agent call reaches a local model
The model call leaves Shuffle from the execution side of the platform, so that is where network access to the model server has to be planned. Shuffle's server side is a frontend, a Go backend API on port 5001 and an OpenSearch document database. The runtime side is Orborus, which polls the backend for jobs. For each workflow execution it starts a worker, and the worker starts the app containers that perform each step. In a simple case, a workflow reaches an agent step, the step sends a request to a model endpoint, and the response returns into the workflow as step output for the next action. Confirm in your own deployment which container actually makes the HTTP request to the model, because that container's network path determines what must be allowed.
Ollama and vLLM both answer over HTTP, which is why either can sit behind this path. Ollama exposes a REST API on port 11434 with OpenAI compatibility, so clients written for the OpenAI API can use its compatible routes. By default it binds to 127.0.0.1 on that port, which means a runtime container on another host cannot reach it until you change the bind address with the OLLAMA_HOST variable and place a proxy in front. vLLM started with vllm serve exposes OpenAI-compatible endpoints, including /v1/chat/completions, /v1/completions, /v1/responses and /v1/embeddings. An application written for the OpenAI API can point its base URL at either server, but the model name and request format must match the server you run.
Authentication differs between the two, and that changes where controls belong. The local Ollama API at localhost:11434 requires no authentication, so anything that can reach the port can send prompts to it. The vLLM --api-key option protects only the /v1, /v2, /inference and /cohere routes. It does not cover endpoints such as /metrics or /health, and the vLLM security documentation warns against relying on it alone. It recommends a reverse proxy that allowlists only the endpoints users need. Both servers therefore need a network boundary around them, such as a dedicated subnet or firewall rule that admits only the runtime hosts. Plan the proxy and the allowlist during the build, before any workflow depends on the endpoint.
Before you build, confirm three things in the Shuffle version and configuration you intend to run. First, find out how the agent step selects the endpoint and the model, whether through step fields, app configuration or environment settings. This detail is not settled by the architecture alone, so check it against your chosen image tag. Second, confirm which container performs the call and that it can resolve and reach the model host from the Orborus host network. Third, verify how the response is parsed into the workflow by running a test call with a known prompt and reviewing the stored output. Record the results in your test plan, and repeat the request path test whenever you change the Shuffle version or the model server.
Setting up a self-hosted model endpoint for Shuffle agents
This sequence takes a self-hosted model runtime from capacity planning to a tested Shuffle agent run, with the endpoint kept on a private network and behind an allowlisted proxy. The result is a model endpoint that answers only the Orborus runtime and stores its models on a volume you back up. Each step closes with a check your team can record before moving on.
Size capacity for the chosen model
Start by choosing the model and runtime, then confirm with the model provider and the runtime documentation what memory and accelerator capacity it needs. Ollama runs on macOS, Windows, Linux and Docker and can use GPU or CPU hosts, while vLLM runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs and on several CPU architectures. Record the number of concurrent agent runs you expect, because Ollama queues requests according to OLLAMA_NUM_PARALLEL and OLLAMA_MAX_QUEUE. The step is done when the team holds a written sizing note that names the model, hardware, concurrency settings and the people who approved them.
Install the runtime on an isolated host
Install either Ollama or vLLM on a host that only the Orborus runtime can reach, and keep it out of any segment where user devices or the internet can connect. For vLLM, start the server with vllm serve on an isolated network, because the vLLM security docs state that communication between nodes in a multi-node deployment is insecure by default. Pin the runtime version you tested and record it in the change record. The check is that the port answers from the Orborus host and does not answer from a workstation on the user network.
Set the Ollama bind address and model store
For Ollama, set OLLAMA_HOST so the server listens only on the internal interface that Orborus uses. The default bind is 127.0.0.1 on port 11434, so a separate host cannot reach it until you change this setting. Point OLLAMA_MODELS at a volume that your backup job covers, and set OLLAMA_NO_CLOUD=1 to turn off cloud features. Pull the model and confirm its files appear in the new directory. The check is that the listener is bound to the expected interface and that the API does not answer from a host outside the allowed network, since the local API has no authentication of its own.
Place a reverse proxy with allowlisted paths
For vLLM, put a reverse proxy in front of the endpoint and forward only the paths Shuffle needs, such as the chat completions path under /v1. The vLLM --api-key option protects /v1 but not /metrics, /health, /invocations or the pause, resume and abort endpoints, and the vLLM security docs warn against relying on the key alone. Require authentication at the proxy and deny all other paths by default. The check is that requests to /metrics and /health through the proxy are refused, and a test prompt sent to the chat completions path returns a model response. Apply the same allowlist and authentication to Ollama.
Register the endpoint as the agent model source
In Shuffle, add the proxy address as the model source for the agent and enter the credential the proxy expects. Store that credential as a saved credential rather than placing it in workflow text, because Shuffle encrypts saved app credentials in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Keep a secure copy of that secret, since the Shuffle configuration docs warn that losing or changing it breaks all saved app authentications. Confirm the exact field names in the Shuffle version you run. The check is that the agent shows the endpoint as its model and the connection test succeeds.
Run a test workflow and review the trace
Build a small test workflow that gives the agent a sample alert built from synthetic data and runs it through the self-hosted endpoint. Confirm that the run completes, that the model call appears in the execution trace, and that the output matches what the prompt asked for. Run the same prompt twice to see whether handling is consistent. The check is that the trace shows the call went to the proxy address, and that the Ollama or vLLM logs show the request arrived. Store the test result and the network check with the change record.
Keeping a person in the loop and reviewing what the agent did
An approval gate and a complete execution record matter most when an agent's output can change a live system, such as isolating a host, disabling an account or blocking an address. A model's recommendation is generated from prompts and alert data, so the playbook needs a defined point where an analyst confirms the action before it runs. Shuffle workflows are built from triggers, actions and conditions, and the human approval pattern described on the workflow triggers and human approvals page applies to agent steps as well. Confirm in the Shuffle version you run whether an agent's output can be routed to a user input step, and whether each agent tool call appears as its own step in the execution view. Until you have checked both, treat agent-initiated containment as unverified.
Before building anything, write down which agent outputs are allowed to trigger actions. A practical split is to let read-only work such as enrichment, lookups, summaries and tagging run automatically, and to require an approval step for anything that changes state on endpoints, identities, network devices or cloud resources. Name an owner for that list and a process for changing it, and keep the change record with the workflow version. Check also that the credentials the agent's tools use are saved through Shuffle's credential store, which encrypts them in OpenSearch, and that the SHUFFLE_ENCRYPTION_MODIFIER value is backed up in a location separate from the platform. The configuration docs warn that losing or changing that value breaks every saved app authentication.
Confirm where Shuffle writes workflow execution records in OpenSearch, which indices and index patterns hold them, which roles can read them and which roles can delete them. Then set retention in writing. The period should follow your incident investigation needs and any records obligations you carry, not the platform default you happen to find. Make sure the OpenSearch snapshot schedule matches that retention, so that expired records are not quietly restored from older backups. Test this with a restore drill that uses a sample execution from an approved workflow. The drill should show who approved the action, what the agent recommended, which model and version produced the output and what the action changed.
Model prompts and responses need a deliberate logging decision. Ollama states that when it runs locally it does not see your prompts or data, but any reverse proxy, gateway or application in front of it may log request bodies. The vLLM metrics endpoint exposes request counts, token throughput, latency and cache use, which is useful for operations but does not show prompt text. Confirm what your serving stack writes to its access and application logs. Then decide what the team records for each agent call, such as model name, version, timestamp, tool invoked, a hash or redacted form of the input and the approval outcome. Strip API keys, tokens, passwords and personal identifiers before anything is written to a log, and give those logs their own access controls and retention period, separate from execution records.
Securing the model path between Shuffle and your models
Shuffle sends alert data and prompts to whichever model endpoint a workflow calls, so each hop between Shuffle and the model needs a deliberate control. The cards cover the model endpoints, the network layout, the stored credentials and the actions an agent can trigger. Work through them before any model receives production alert data.
Keep Ollama off open networks
Ollama's local API on port 11434 has no authentication, and it binds to 127.0.0.1 by default. If you change the bind address with OLLAMA_HOST so Shuffle's workers can reach it, place the listener on a private interface and put an allowlisting proxy in front of it, such as Nginx, as the Ollama FAQ describes. Confirm which hosts can reach port 11434 from your Orborus and worker networks, then test that nothing else can. Cloud inference uses a Bearer API key, so keep local and cloud endpoints in separate configurations.
Expose only the vLLM endpoints users need
Setting vLLM's --api-key protects the /v1, /v2, /inference and /cohere endpoints, but it does not protect /invocations, /pause, /resume, /abort_requests, /metrics or /health. The vLLM security docs warn against relying on the key alone and recommend a reverse proxy that allowlists only the endpoints meant for users. For a Shuffle integration, decide which paths the app needs, usually the chat or completions path, and block everything operational. Test the operational paths from outside the allowed network to confirm the proxy blocks them.
Isolate vLLM multi-node traffic
The vLLM security docs state that communication between nodes in a multi-node deployment is insecure by default, with no authorization or encryption. Multi-node serving uses pipeline parallelism across nodes through Ray or vLLM's multiprocessing backend, so inter-node links carry model execution traffic. Place every node on an isolated network that only cluster members and the approved gateway can reach, and keep the Shuffle-facing API on a separate interface. Ask your platform team to confirm this boundary before go-live.
Protect the encryption modifier
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is lost or changed, all saved app authentications break, including the credentials that connect Shuffle to the model endpoint. Store the value in your secrets manager, record it in your backup runbook, and set it before the first workflow saves a credential. Rehearse a restore from backup to confirm the value is recovered alongside the data it protects.
Set model store and log retention
Ollama stores models in ~/.ollama/models on macOS, /usr/share/ollama/.ollama/models on Linux and the .ollama\models folder on Windows, and OLLAMA_MODELS moves that location. Ollama states that local runs do not expose your prompts or data to it, and OLLAMA_NO_CLOUD=1 turns off cloud features. Decide where Shuffle execution records, workflow results and model logs are kept, how long each is retained and who can read them, since prompts may contain alert content. Confirm retention periods with your compliance owner and enforce them in your storage and log platform.
Gate agent actions behind approvals
An agent that can call tools can also trigger containment, ticket changes or account actions, so model output should not run those steps unchecked. Shuffle workflows can pause at user input steps so an analyst approves a defined action before it runs. Map each tool the agent can reach to a tier: read-only lookups, reversible changes and actions that require approval. Review the execution trace for each approved run, and confirm in your Shuffle version how approval prompts are delivered and recorded.
What drives the cost of local models compared with Shuffle Cloud credits
The largest cost of a self-hosted model is the capacity to run it, not a licence fee. vLLM has no paid edition and is licensed under Apache-2.0, so the cost of running it comes from GPU or other accelerator capacity, the surrounding infrastructure, implementation and the people who operate it. Ollama's pricing page states that running models on your own hardware is always unlimited. Its paid plans (Pro, Max, Team and Enterprise) apply only to the cloud models it hosts, and a local Ollama deployment does not need one. Ask the partner or your procurement team to confirm this in writing for each runtime and for any hosted feature you might switch on, because the cost model changes if a workflow calls a hosted model.
Four lines make up the self-hosted cost. The first is accelerator or server capacity, which depends on model size, quantization, the number of concurrent requests and the GPUs needed for tensor parallelism. Ollama's OLLAMA_NUM_PARALLEL and OLLAMA_MAX_LOADED_MODELS settings and vLLM's parallelism options determine how much memory you must reserve. The second is storage for model files, which you should size for every version you keep for rollback. The third is the surrounding infrastructure: the Shuffle backend and OpenSearch, Orborus runtime nodes, a reverse proxy that allowlists only user-facing vLLM endpoints, and a metrics store. The fourth is implementation effort and ongoing operations. Each line should appear as a separate item in the quote.
The Shuffle side is metered differently. Shuffle licensing is priced on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. The decision that changes your bill is whether an AI agent's model calls, and the MCP tool actions it invokes, consume app runs or draw from separate Shuffle Cloud credits. Ask Shuffle this in writing before design starts, and ask whether the answer differs between self-hosted, hybrid and Cloud deployments. If model calls are metered separately, the cost of local inference is avoided only for the model layer, while the tool actions in the same workflow may still count toward app runs.
Separate one-time work from recurring cost when you compare options. One-time costs include architecture design, model selection and testing, integration with Shuffle workflows and approval steps, network isolation and hardening, and verifying that execution traces capture each agent decision. Recurring costs include the hardware or cloud bill, storage growth, model upgrades that need re-testing, monitoring, and security patching of Shuffle, the runtime and the proxy. Release cadence matters here: vLLM ships new minor releases about every two weeks and Ollama releases frequently. In the quote, request itemized hardware and storage, the metering answer in writing, the support window, the upgrade approach, and a clear list of exclusions.
Limits to confirm before you commit to a local model
Six items in a Shuffle and local model design can change what works in your environment, and each one needs a check before you commit. They cover the Shuffle release baseline, the agent step's endpoint configuration, Ollama and vLLM capacity behavior, triage quality and the edition limits that apply to Shuffle Cloud.
Shuffle version and MCP support
Agent and MCP features do not appear in every release, so confirm which Shuffle version in your environment exposes them before you design around them. Start from the version you run today. Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026, so an older deployment may need an upgrade before any agent work begins. Check the release notes for the version you plan to deploy, and pin the Docker tag you test against, since the docs recommend the latest tag for stable releases and the nightly tag for experimental changes.
Custom OpenAI-compatible base URL
Confirm that the agent step accepts a custom OpenAI-compatible base URL, because that setting determines whether Ollama or vLLM can be used without custom code. Test it against your actual model server, including the chat endpoint path and how the step handles an API key header that a local server may ignore. Ollama serves an OpenAI-compatible API on port 11434, and vLLM exposes /v1/chat/completions, so both are candidates once the base URL is configurable in the step.
Ollama parallelism and queue limits
Ollama defaults to one parallel request per model through OLLAMA_NUM_PARALLEL and holds up to 512 queued requests through OLLAMA_MAX_QUEUE. During a busy period, alerts that trigger many agent calls wait in that queue, so the playbook sees slower responses long before any error appears. Measure how long a burst of your typical alert volume takes to clear with these defaults. Then decide whether to raise parallelism, run more model instances or limit how many agent runs start at once in Shuffle.
vLLM multi-node and accelerator support
vLLM support depends on your hardware. It runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, on several CPU architectures and on other accelerators through third-party plugins. Multi-node serving splits a model across nodes with pipeline parallelism, using Ray or the built-in multiprocessing backend. The vLLM security docs state that traffic between nodes is unauthenticated and unencrypted by default, so confirm an isolated network design before you plan a second node. Validate your exact accelerator and model combination with the vLLM project and your hardware vendor.
Model quality for triage tasks
A model that Ollama or vLLM can serve has not been shown to classify alerts, summarize logs or propose containment steps accurately enough for your use. Build a labeled set from your own alerts, including benign noise and known incidents, and score each candidate model on the output format your playbook parses. Also confirm that the model handles the context length and tool calls the agent step needs, because a model that answers well in chat can still fail to call tools reliably.
Shuffle Cloud and edition limits
Shuffle states that the limits between the open-source and enterprise editions have been enforced since v2.1.1, so a feature you test in one edition may be restricted in another. SAML single sign-on is being deprecated on Shuffle Cloud in favor of OpenID Connect, and licensing counts app runs. Ask Shuffle in writing which agent, MCP and SSO features apply to the edition and deployment type you plan to run, and keep the cloud inference path on a separate cost line from local compute.
Questions teams ask before running Shuffle agents on their own models
Can our team set up Shuffle agents on self-hosted models without a partner?
Yes, if your team already runs Docker, Linux and internal services and has someone who can operate a model server. Shuffle, Ollama and vLLM all publish documentation, and Ollama and vLLM are open source. The work still includes choosing hardware, placing the model server on a network Shuffle can reach, adding access controls in front of the API, validating the models your agents need, and configuring Shuffle's agent and tool settings. Teams that lack spare capacity, or that need a fixed completion date and a written scope, often bring in a partner for part of the work. A partner can also run the work as a fixed-scope engagement with the handover documented.
How much effort does a self-hosted model setup for Shuffle agents take?
The effort depends mostly on the serving engine, the hardware and the number of users or workflows that call the model. Ollama is the simpler starting point for a small deployment because it runs on common operating systems and exposes a local REST API on port 11434. vLLM takes more planning because it is designed for GPU-backed serving, may need multiple GPUs or nodes for larger models, and has a multi-node security model that requires an isolated network. Other drivers include how many models you need, how many concurrent requests agents will generate, whether you need high availability, and how much logging and monitoring your security team expects. Ask for an effort estimate that lists each of these drivers separately.
How long does setup take, and what determines the timeline?
The timeline is set by hardware availability, the size of the agent use cases, and how many approvals the change needs. A single-node Ollama deployment for a limited pilot can be simpler than a multi-node vLLM service with access controls, monitoring and a tested failover path. Procurement or delivery lead times for accelerators often matter more than the software work. Network changes, firewall reviews, identity integration and sign-off from security or change boards also add time. Shuffle's own deployment choice matters too: a single Docker Compose server, a Swarm or Kubernetes layout, or a hybrid with a local Orborus each has a different preparation list. Ask for a timeline that starts after hardware is confirmed and lists the approvals in order.
What does the work need from our internal team?
Your team needs to decide what the agents may do, own the network and identity decisions, and provide people who can run the model service after handover. Typical inputs include the list of Shuffle workflows that will call a model, the data classes those workflows touch, the network segments where the model server can live, and the identity provider used for operator access. Your platform team usually supplies container hosts or Kubernetes access, storage, DNS and certificates. Your security team should review the allowed endpoints, logging and retention. After the build, someone must own model updates, Shuffle version upgrades and capacity checks. Name these owners before the work starts so the handover is not left open.
Does alert data leave our network with Ollama or vLLM?
With a model server running inside your network and no cloud calls enabled, alert data stays inside your infrastructure. Ollama states that when it runs locally it does not see your prompts or data, and you can turn off cloud features with OLLAMA_NO_CLOUD=1 or in the server configuration file. Direct cloud inference at ollama.com requires an API key, so any option that uses those endpoints sends prompts outside your network. vLLM serves its own endpoints, but its docs warn that the --api-key option is not enough alone, so a reverse proxy should allowlist only the endpoints users need. Routing inference to Shuffle Cloud credits sends the data to the Shuffle service, so confirm the data path in writing with Shuffle before you choose that option.
Which costs recur and which are one-time when running Shuffle agents on self-hosted models?
Hardware and infrastructure costs usually recur, while design, configuration and validation are typically one-time. Ollama's pricing page states that running models on your own hardware is always unlimited, so the software itself carries no license fee for local use. Its paid cloud plans, such as Pro at $20 per month, apply only if you use its hosted models. vLLM has no paid edition, so its cost comes from accelerator capacity, the surrounding infrastructure and the people who operate it. Shuffle licensing is priced on app runs, which are actions that actually execute in a workflow, so agent-driven steps may count toward that metric depending on your tier. Recurring items also include power, support, upgrades and monitoring. Ask a quote to separate one-time build work from these recurring items.
How do we ask for a fixed-scope quote for this work?
Send a written list of the outcomes you need, the environment details and the decisions your team has already made, then ask for a fixed scope. Include the Shuffle deployment type, the target model server (Ollama, vLLM or both), the hardware you already own or plan to buy, the network zones involved, the identity provider, the number of workflows that will use agents, and whether you need high availability or monitoring. Ask which items are included, which are excluded, what your team must provide, and what acceptance tests will prove each deliverable. DeployOpen works from a written scope, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Quotes follow from that scope, so the more specific the request, the more precise the quote.
How DeployOpen scopes and delivers Shuffle agent work
DeployOpen plans and builds Shuffle AI agents and MCP tools against model endpoints you run, including Ollama or vLLM, inside your own infrastructure. The work covers the Shuffle deployment, the model runtime, approvals and execution traces, and the controls around them. Each engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- The written scope names each Shuffle agent, its MCP tools, and the alert data it may read.
- We record which model runs each agent, whether it is Ollama or vLLM, and where it is hosted.
- Any route that sends prompts to Shuffle Cloud credits or ollama.com is scoped and approved separately.
How we build
- We deploy the Shuffle server and Orborus on the chosen architecture, keeping model endpoints on a private network segment.
- Ollama listens only on localhost by default, so network exposure is a deliberate build step with a proxy.
- For vLLM, we treat --api-key as one control and allowlist only user-facing endpoints behind a reverse proxy.
How we hand over
- We test agent approvals, tool permissions and execution traces against the scope before sign-off.
- Documentation covers model storage paths, OLLAMA_NO_CLOUD settings, concurrency limits and the proxy allowlist.
- Handover notes explain SHUFFLE_ENCRYPTION_MODIFIER, since changing it breaks saved app authentications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Retainers can cover Shuffle and Ollama or vLLM version reviews, since both projects release often.
- Confirm your Shuffle Docker tag policy, since the docs recommend latest for stable and nightly for experimental.
