When self-hosted Ollama fits and when Ollama Cloud fits
Choose local Ollama when data residency and no-cloud rules dominate the decision, and choose Ollama Cloud when you lack the hardware and the workload is small enough to live within usage credits and concurrency caps. Your team wants open models behind the same CLI and API either way, so the real question is where prompts and responses are allowed to be processed. Local inference is the stronger fit when a policy requires that data never leave your infrastructure, because local models run on your own hardware and Ollama's pricing page lists that usage as always unlimited. Cloud models, by contrast, are called through the ollama.com API and run without downloading weights, so every prompt leaves your network boundary.
Local operation has a cost that is easy to miss: you buy and run the hardware, and you own capacity planning. Ollama's default of one parallel request per model (OLLAMA_NUM_PARALLEL) means a shared internal assistant will queue quickly unless you size the server and tune the concurrency settings. Ask your platform team to measure throughput on the exact model and GPU or CPU they plan to use before they promise a service level to users. Local Ollama also does not need an API key on localhost, so access control must come from your network design and a reverse proxy, not from Ollama itself.
Ollama Cloud fits a different situation: a small group of developers who need frontier-scale models without a GPU budget, and whose usage stays inside the included credits. Cloud usage is metered by tokens at each model's rates, included credits do not roll over, and concurrency is capped at 1 request on Free, 3 on Pro and 10 on Max and Team, with extra requests queued. Confirm the current rates and off-peak windows on the pricing page before you model costs, and check that Ollama's no-logging and zero data retention statements satisfy your legal review. Ollama states that hosting is primarily in the United States with possible routing to Europe, so a residency requirement should be answered in writing before you pilot.
Ollama local versus Ollama Cloud, factor by factor
This table compares how the same Ollama CLI and API behave when models run on your own hardware versus on Ollama's hosted cloud. Read each row as a vendor statement from Ollama's pricing, docs and FAQ unless you verify it in your own environment. The main takeaway is that local use is unlimited and keeps prompts on your hardware, while cloud use adds per-token credits, concurrency caps and retirement dates you must track.
| Factor | Local Ollama | Ollama Cloud models |
|---|---|---|
| License | Ollama runtime is MIT licensed (Ollama GitHub repository). Model weights carry their own licenses, so check each model. | Cloud service terms apply. Confirm the current terms on the pricing page before you rely on them. |
| Where inference runs | On your own hardware, bound to 127.0.0.1:11434 by default. | Hosted by Ollama, mainly in the United States, with possible routing to Europe for extra capacity (Ollama pricing FAQ). |
| Authentication | Local API at localhost:11434 requires no authentication. Add a proxy if you expose it. | API key sent as a Bearer token to ollama.com/api or ollama.com/v1 (Ollama API authentication docs). |
| Plan prices and included credits | Running your own models is always unlimited, per Ollama's pricing page. No Ollama subscription is needed to run them. | Free includes starter credits. Pro is $20 per month or $200 per year with $60 monthly credits. Max is $100 per month with $300 credits. Team is $500 per month with $1,000 shared credits (Ollama pricing page). |
| Concurrency limits | Default of 1 parallel request per model (OLLAMA_NUM_PARALLEL), with a queue of 512 (OLLAMA_MAX_QUEUE), per the Ollama FAQ. Tune these on your own hardware. | 1 request on Free, 3 on Pro, and 10 on Max and Team. Extra requests queue, and are rejected when the queue is full (Ollama pricing FAQ). |
| Logging and data handling | Ollama states that when it runs locally it does not see your prompts or data. Your own logging policy still applies. | Ollama states it never logs or trains on prompt or response data, and partners with NVIDIA Cloud Providers under zero data retention terms. These are vendor statements, so confirm them in writing for your contract. |
| Model retirement | Downloaded local models are not affected by cloud retirement dates. | Cloud models may be retired on dates shown in usage settings. Check them before you build on a specific model. |
| Local-only lock | Not applicable. Local use runs without cloud access. | Cloud access can be removed with disable_ollama_cloud in ~/.ollama/server.json or OLLAMA_NO_CLOUD=1, then restarting. This also removes web search. Confirm the setting after each upgrade. |
How Ollama Cloud usage is metered and what the credits cover
Ollama Cloud usage is metered in tokens, priced at each model's per-million-token input, cached input and output rates. A request to a cloud model draws down your included credits at those rates, so the same plan can cover very different amounts of work depending on which model you call and how long prompts and responses run. Off-peak pricing applies outside 12:00 to 18:00 UTC on weekdays and all day on weekends. If your team's jobs can be scheduled into those windows, the metered cost of batch work may fall, but you should confirm with Ollama how the off-peak rates apply to each model in the pricing page before you plan around them. Included credits do not roll over, so unused credits at the end of a period are lost.
The cost of cloud use has three parts. The first is the plan fee: Pro, Max or Team, billed monthly or, for Pro, annually. The second is metered usage beyond the credits in your plan. The third sits on your side of the comparison: the hardware, power, hosting and staff time needed to run models locally. Running models on your own hardware is always unlimited in Ollama's pricing, so the local side has no per-token fee, but it does carry a one-time or recurring infrastructure cost and the engineering time to operate it. Cloud usage also has a recurring cost that scales with use, which is why credits and budgets should be reviewed against actual consumption each month.
Before you commit to Team or Enterprise, ask Ollama for the exact per-million-token rates for every model your workloads need, the rules for off-peak pricing, and how usage above the included credits is billed and capped. Ask how cost budgets for users and API keys work on Enterprise, and whether those budgets are enforced before or after a request is served. Ask which data residency applies to metered traffic, since Ollama says it hosts primarily in the United States and may route to Europe for extra capacity. Confirm whether the figures you receive apply to your contract, and get them in writing with the plan terms.
How data location and logging change the compliance picture
Local and cloud Ollama differ most on where prompts travel and who holds the access keys. The cards below separate what Ollama states about local runs from what it states about hosted inference, and list the evidence a compliance team should request before approving either path.
Local prompts stay on your hardware
Ollama states that when it runs locally it does not see your prompts or data. For a regulated team, that means the data path for local models stays inside hosts you already assess. Confirm the statement in writing with Ollama, then document the hosts, disks and network segments that actually handle prompts, since your own logging and backups are now the only record that matters.
Cloud inference runs mainly in the US
Ollama says it hosts cloud models and compute primarily in the United States and may route to Europe for extra capacity. If your data residency rules name specific regions, this routing is a gap to close before any prompt leaves your network. Ask Ollama which regions serve your account, whether routing can be pinned, and how the answer is documented for your assessor.
No-logging and no-training terms
Ollama states that it never logs or trains on prompt or response data and that its NVIDIA Cloud Providers partnership runs under no-logging, no-training and zero data retention policies. These are vendor statements, not contract terms you can audit yourself. Request the written policy and any data processing terms, and confirm whether they cover subprocessors and the Europe routing path.
API keys as the cloud access control
Cloud calls to ollama.com/api and ollama.com/v1 require an API key sent as a Bearer token, so that key is the only gate between your code and your paid usage. Assign keys per workload, store them in a secrets manager, rotate them on a schedule your policy sets, and remember that Enterprise adds cost budgets per user or API key. Without these controls, a leaked key exposes both data and billing.
Unauthenticated local API on port 11434
The local API at localhost:11434 does not require authentication, and Ollama binds to 127.0.0.1 by default. Changing OLLAMA_HOST to a shared address without a proxy in front exposes an unauthenticated inference endpoint to the network. Put a reverse proxy such as Nginx with authentication and TLS in front of any shared bind, and test that the port is unreachable from other segments.
Evidence your assessor will ask for
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors do. For either path, collect the vendor's written data handling terms, your network diagrams, key inventories, the OLLAMA_NO_CLOUD configuration for local-only hosts and the access logs your proxy keeps. Confirm with your assessor which of these they accept as evidence.
Locking an installation to local models only
On a single workstation, the simplest lock is the configuration file or the environment variable. Ollama reads cloud settings from ~/.ollama/server.json, where the key disable_ollama_cloud turns off Ollama's cloud models and web search. You can also set OLLAMA_NO_CLOUD=1 in your shell or service environment. Either way, the change only takes effect after you restart Ollama, so a running server keeps its old behavior until then.
- Config file key: add
disable_ollama_cloudto~/.ollama/server.jsonand restart the application. - Environment variable: set
OLLAMA_NO_CLOUD=1where Ollama starts, which is useful if you manage the setting per user session. - Scope of the lock: cloud models and web search stop working, while models you have already downloaded keep running.
- Default bind: the server listens on
127.0.0.1:11434, so other machines on your network cannot reach it unless you change that. - Local data: the FAQ states that local runs do not expose your prompts to Ollama.
After restarting, confirm that a cloud model name no longer resolves and that localhost:11434 still answers requests for a downloaded model.
On a Linux server, Ollama usually runs as a system service, so the environment variable has to be set in the service definition rather than in an interactive shell. The OLLAMA_NO_CLOUD=1 variable or the server.json key must be visible to the account that runs the service, and the service must be restarted afterward. Confirm which user owns the model directory, since the FAQ places models under /usr/share/ollama/.ollama/models by default.
- Service override: add
OLLAMA_NO_CLOUD=1through a systemd override so the setting survives reboots. - Config location: when you use the file, check that
server.jsonsits under the home directory of the service account, not your administrator account. - Bind address: the default is
127.0.0.1:11434. ChangingOLLAMA_HOSTto a network interface exposes the API to that network. - Reverse proxy: the FAQ describes exposing Ollama through proxies such as Nginx. The proxy must add its own authentication and TLS, because the local API does not require authentication.
- Model location:
OLLAMA_MODELSmoves storage, so keep it consistent when you audit what is on disk.
Before you go live, check the bound address with your operating system's socket listing and confirm that port 11434 is not reachable from outside the host.
In a container, the lock is usually an environment variable passed at run time, because the configuration file lives inside a volume that you may not inspect often. The FAQ's OLLAMA_NO_CLOUD=1 setting belongs in the container definition, and the container must be recreated or restarted for it to apply. The bind address also needs care, because a container that listens on all interfaces inside its network namespace may publish the port to your host or to the network.
- Run-time variable: pass
OLLAMA_NO_CLOUD=1in thedocker runcommand or the Composeenvironmentblock. - Persistent config: if you use
server.json, mount it as a read-only file so the lock cannot be edited from inside the container. - Port publishing: bind the published port to
127.0.0.1on the host, or keep it off the public interface entirely. - Bind inside the container: if you change
OLLAMA_HOSTinside the image, check that the container's published ports match your intent. - Image versioning: pin the image tag so that a pull does not change the behavior you tested.
After deployment, run a cloud model request from inside the container and confirm that it fails, then check the host's published ports with your container runtime's inspection command.
On Windows, the lock can be set as a user or system environment variable, or through the server.json file in your .ollama folder. The FAQ places models in the user's .ollama\models folder by default. Because Ollama on Windows often starts from the tray application, a change made to environment variables is only seen after the application fully exits and starts again. Sign out and back in, or restart the machine, if the tray process still holds the old values.
- Environment variable: set
OLLAMA_NO_CLOUD=1as a user variable for a single account, or as a system variable for every account on the machine. - Config file: place
disable_ollama_cloudin theserver.jsonfile under the user profile that runs Ollama. - Restart check: quit Ollama from the tray, start it again and test a cloud model name.
- Firewall: Windows Defender Firewall may prompt when a process listens on a network interface. Decline unless you have a reviewed reason to expose the API.
- Model folder:
OLLAMA_MODELScan point storage to another drive, which matters for disk encryption and backup scope.
After the restart, confirm the lock with a cloud model request and confirm that the port is bound only to the loopback address.
What your team runs in each model
This table compares the work each model leaves to your team, from hardware and storage to concurrency, release tracking and cloud key management. Read each row as a question to answer before choosing, since local runs put the work on your hardware and cloud runs put it on your accounts and budgets.
| Area | Local Ollama on your hardware | Ollama Cloud models |
|---|---|---|
| Hardware and GPU procurement | Your team sizes and buys CPU, memory and GPU capacity for the model sizes you intend to run. Ask your hardware vendor to confirm fit for each model. | No local hardware for inference. Capacity is hosted by Ollama, so procurement shifts to network and egress planning. |
| Model storage | Weights live in ~/.ollama/models on macOS, /usr/share/ollama/.ollama/models on Linux or the .ollama\models folder on Windows. Set OLLAMA_MODELS to move them and plan disk for each model you keep. | Models run without downloading weights, so there is no local model store to size or back up for cloud calls. |
| Concurrency tuning | Set OLLAMA_NUM_PARALLEL (default 1 per model), OLLAMA_MAX_LOADED_MODELS (default 3 per GPU, or 3 on CPU) and OLLAMA_MAX_QUEUE (default 512). Load-test your own hardware before setting these. | Limits are set by the plan: 1 concurrent request on Free, 3 on Pro, 10 on Max and Team, with queuing and rejection beyond the queue, per the Ollama pricing FAQ. |
| Access and key management | The local API on localhost:11434 has no authentication by default. Your team controls network exposure, for example through a reverse proxy such as Nginx. | Each cloud call uses an API key sent as a Bearer token. Assign keys per user or service, rotate them and confirm revocation steps with Ollama. |
| Budgets and spend control | No per-token bill. Your cost is hardware, power and operations, which you track in your own systems. | Usage is metered in tokens with credits that do not roll over. Enterprise adds cost budgets per user or API key, so confirm this control is in the plan you buy. |
| Model retirement monitoring | Downloaded local models are not affected by cloud retirements, so your team chooses when to upgrade or replace weights. | Cloud models may be retired on dates shown in usage settings. Assign an owner to check those dates and test replacements before they take effect. |
| Release tracking | Track Ollama releases yourself. v0.40.5 was released on 14 October 2026 and v0.40.6 was published as a pre-release on 16 October 2026, so test pre-releases before rolling them out. | Ollama manages the cloud service side. Your team still tracks client library and API changes in the applications that call it. |
| Data handling controls | Ollama states that local runs do not see your prompts or data. Use OLLAMA_NO_CLOUD=1 or the server configuration file to block cloud access on hosts that must stay local. | Ollama states it never logs or trains on prompt or response data and partners under zero data retention policies. Confirm these terms against the contract you sign. |
Moving between local Ollama and Ollama Cloud
This sequence lets a team move a client from local Ollama to Ollama Cloud models, or back again, with a clear record of which models run where and which ones need replacing before they retire.
Inventory every client and model in use
The platform or application owner lists each client, script and integration that calls Ollama, along with the model names each one sends. Record whether each call goes to localhost:11434 or to a remote host, and note any tool that uses the OpenAI or Anthropic compatible paths. Done means every caller has an owner and a current model name in a written list that the team can check against later steps.
Decide which models move to cloud
The team lead and the data owner decide, model by model, whether a given workload may send prompts and responses to Ollama's hosted models. Ollama states that it never logs or trains on prompt or response data and hosts cloud compute primarily in the United States, with possible routing to Europe for extra capacity. Confirm those terms against your own data classification, because the vendor statements do not replace your review. Done means each model carries a written local or cloud decision.
Switch a test client to cloud
An engineer changes the endpoint in one non-production client to the ollama.com API or its compatible path and adds an API key sent as a Bearer token. Cloud models run without downloading weights, so no local pull is needed for them. Test the model name, streaming, tool calls and any structured output the client depends on, because compatible clients may not cover every feature. Done means the test client returns expected results from a named cloud model in a test environment.
Move the approved client to cloud
Once the test passes, the platform owner rolls the change into the approved client's configuration and stores the API key in your secrets manager instead of in code or shared files. Check the account's concurrency limit for its plan before cutover, since requests beyond the limit queue and are rejected when the queue is full. Done means production traffic for that client reaches the cloud endpoint and the key is managed under your normal rotation process.
Download weights to move back to local
To return a workload to local inference, an operator pulls the required model onto the server with Ollama, then points the client back to the local API at localhost:11434 or your proxied address. Local models are stored in the directory the server uses by default, or in the path set by OLLAMA_MODELS. Done means the model appears in the local model list and a test request from the client returns a response with no cloud call.
Enable local-only mode on the server
The server administrator enforces local-only operation by setting disable_ollama_cloud in ~/.ollama/server.json or the OLLAMA_NO_CLOUD=1 environment variable, then restarts the service. Ollama documents that this removes access to its cloud models and web search. Done means a cloud request from that host fails, and a change record shows the setting in the server configuration.
Track retirement dates in usage settings
The model owner checks the retirement dates shown in Ollama's usage settings on a fixed schedule and records each cloud model's date beside its client. Ollama notes that cloud models may be retired on those dates, while downloaded local models are not affected. Plan a replacement model, test it in the same way as earlier steps, and cut over before the date. Done means every cloud model has a dated owner and a tested fallback.
Confirm each model and endpoint in a test environment
Before any switch in either direction, the QA or platform engineer runs the client's full test suite against the exact model, endpoint and key combination that will go live. Compatible clients reduce code changes but may not expose every feature the vendor offers, so confirm each one rather than assuming parity. Ask Ollama about any feature you need that is not in its documentation. Done means a signed test record exists for each model and endpoint pair.
Where a hosting decision needs outside engineering
A local Ollama installation is a service you operate, and the work around it is where outside engineering usually helps. Ollama binds to 127.0.0.1 on port 11434 by default, and its local API does not require authentication. Moving it onto a shared network means someone has to decide the bind address through OLLAMA_HOST, place an authenticated reverse proxy such as Nginx in front of it, and confirm that nothing reaches the port directly. DeployOpen scopes this work: sizing the hardware against the concurrency settings you need (OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE), building the proxy and access layer, and testing the API surface after it is exposed.
Locking the configuration is the second area. Cloud features can be disabled with OLLAMA_NO_CLOUD=1 or the disable_ollama_cloud setting in ~/.ollama/server.json, which also removes web search. Those controls only hold if every host is configured the same way and the setting survives restarts and upgrades. Assessors will also want a data flow document that shows where prompts and model files sit, which directory holds the models, and which paths leave the network. Ask for this as a written deliverable, and confirm with Ollama's FAQ which claims about local data handling apply to your version.
Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish prices, and a quote follows from that written scope, so a useful request names the number of servers, the users who will reach the service, the proxy and identity integration you need, and whether you want the API tested and the configuration documented. Ongoing upgrades and testing are available as retainers. Compare any quote against the cost of Ollama Cloud plans, which recur monthly or annually, because a local deployment shifts that spend toward hardware and internal operating time.
Questions buyers ask before choosing Ollama hosting
What does Ollama Cloud cost at each published plan level?
Ollama Cloud is priced by plan, and the published tiers are Free, Pro, Max and Team, with Enterprise available on custom terms. Pro is listed at 20 US dollars per month or 200 per year and includes 60 dollars of monthly usage credits. Max is listed at 100 dollars per month with 300 dollars of credits, and Team is listed at 500 dollars per month with unlimited users and 1,000 dollars of shared credits. Free includes starter credits for starter models only. Usage above credits is metered in tokens at each model's per-million-token input, cached input and output rates, and off-peak pricing applies outside 12:00 to 18:00 UTC on weekdays and all day on weekends. Included credits do not roll over, so check the current rate card for each model you plan to use before you commit to a plan.
Is local Ollama really unlimited, and what does it cost to run?
Ollama's pricing page states that running models on your own hardware is always unlimited, so there is no per-token license fee for local inference. The real costs are hardware, power, storage for model files and the staff time to operate the server. Model size, quantization, context length and the number of parallel requests all set how much memory and GPU capacity you need, so benchmark your target models on the hardware you plan to buy or rent. Hardware is a one-time or capital cost, while power, maintenance and engineering time recur. Ask your team who will patch the host, monitor it and handle model updates, because that person's time is the largest unknown in the total.
How do concurrency limits change throughput, and when should I move to a multi-user server?
Concurrency limits decide how many requests run at once and how many wait. Cloud concurrency is set at 1 request on Free, 3 on Pro and 10 on Max and Team, with requests queued beyond the limit and rejected when the queue fills. Locally, OLLAMA_NUM_PARALLEL defaults to 1 parallel request per model, OLLAMA_MAX_LOADED_MODELS defaults to 3 times the number of GPUs (or 3 on CPU) and OLLAMA_MAX_QUEUE defaults to 512 queued requests. If several users or services send traffic at the same time, a single default setup will queue work and slow responses. Raising these values uses more memory, so test them under realistic load. When many concurrent users are the main requirement, compare Ollama with a server designed for batching, such as the vLLM comparison pages in this group.
Does Ollama log my prompts in cloud, and how do I confirm that in writing?
Ollama's FAQ states that it never logs or trains on prompt or response data for cloud models, that it hosts cloud models and compute primarily in the United States, and that it may route to Europe for extra capacity. It also says it partners with NVIDIA Cloud Providers under no-logging, no-training and zero data retention policies. Those are vendor statements, so ask Ollama for them in writing and in the terms that govern your contract, including any data processing terms your legal team requires. Confirm the data residency and routing you can accept, whether cloud use can be restricted for your organization, and what the Enterprise plan's custom security questionnaire covers. Local runs do not send prompts to Ollama, according to the FAQ.
How do I lock an Ollama installation to local models only, and how do I verify it?
Set disable_ollama_cloud to true in ~/.ollama/server.json, or set the environment variable OLLAMA_NO_CLOUD=1, then restart the server. Ollama's FAQ says this removes access to cloud models and web search. Verify it after the restart by requesting a cloud model and confirming the request fails, by checking that the server reports no cloud access in its logs, and by confirming that outbound traffic from the host to ollama.com is blocked at your firewall or proxy. Make the setting part of your configuration management so a new host or upgrade does not revert it. Also note that the local API on localhost:11434 does not require authentication by default, so restrict network exposure separately.
Can my team run local Ollama ourselves, or do we need outside help?
A small team can install Ollama and run it for experiments, because the runtime is MIT licensed, available for macOS, Windows, Linux and Docker, and exposes an API on port 11434. Production use needs more: a hardened host, a reverse proxy with TLS and authentication if other users reach it, model storage planning, monitoring, upgrades on a frequent release cadence, and a tested rollback. The skills that drive effort are Linux administration, GPU driver and container operations, network security and the ability to size hardware for your models and concurrency. Estimate effort by listing these tasks against the people you have. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, typically under a written, fixed scope, and can also provide ongoing support as a retainer.
How DeployOpen scopes and runs self-hosted Ollama
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so a local Ollama deployment runs on hardware and networks you control. We start from your data rules, user counts and approved hosts, then agree the scope in writing before any work begins.
How we scope
- Written scope states which models run locally, on which hardware, and who can reach the API.
- Scope records whether cloud models are allowed, and if so which data classes they may see.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Install Ollama on your servers or Kubernetes nodes and set OLLAMA_HOST deliberately, not left at default.
- Configure local-only mode with disable_ollama_cloud or OLLAMA_NO_CLOUD=1, then verify it in testing.
- Place an authenticated reverse proxy such as Nginx in front of the local API and set concurrency and queue limits to match load.
How we hand over
- Documentation covers model storage paths, concurrency settings, proxy configuration and the local-only verification steps.
- Handover includes a record of which environment variables and server settings were changed and why.
- Your team receives a written runbook for adding models, restarting the service and checking that cloud access stays disabled.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade work covers new Ollama releases, re-checking the local-only configuration after each one.
- Ask any provider to confirm the current plan terms, credit rules and data handling in writing before you rely on them.
