How to Deploy Gurobi Without a License Server

Here's a question I hear from OR engineers at least once a week: "We've built a great optimization model, but deploying it to production is a nightmare. Is there a way to run Gurobi without managing a license server?"

The short answer is yes. The longer answer involves understanding why Gurobi's licensing model exists, what your actual options are, and which tradeoffs you're signing up for with each approach.

Why License Servers Exist (And Why They're Painful)

Gurobi licenses aren't DRM for the sake of DRM. Floating licenses solve a real problem: you have N users who need occasional access to an expensive solver, and you don't want to buy N separate licenses. A license server lets 5 people share 2 licenses, checking them in and out like library books.

The problem is that this model assumes a world that doesn't exist anymore.

In 2008, when Gurobi was founded, "deployment" meant running a solver on a developer's workstation or a dedicated server in a data center. The license server sat on the same network, everything was colocated, and the whole setup was someone's full-time job to maintain.

In 2025, "deployment" means:

• Ephemeral containers that spin up and down
• Serverless functions that live for milliseconds
• Kubernetes pods that get rescheduled across nodes
• CI/CD pipelines that need to run optimization tests
• Data scientists running notebooks from home

The floating license model actively fights against all of this. Every license checkout requires a TCP connection to the license server. Every network boundary—VPN, firewall, cloud security group—is a potential failure point. Every autoscaling event means coordinating license availability across workers that might not exist in 30 seconds.

I've seen OR teams spend more time debugging license issues than debugging their actual models. That's insane.

Your Actual Options

Let's map the territory. If you want to run Gurobi in production without the traditional license server pain, you have four options:

Option 1: Gurobi Instant Cloud

Gurobi offers their own cloud service. You upload a model, it runs on Gurobi's infrastructure, you get results back.

The good: No license server. No infrastructure. It works.

The bad: Vendor lock-in to Gurobi's specific API. Limited customization. You can't run preprocessing or postprocessing logic alongside the solve. Pricing is opaque (you need to contact sales).

Honest assessment: Fine for simple use cases. Awkward once you need any workflow complexity.

Option 2: Web License Service (WLS)

Gurobi's newer licensing option. Instead of a license server, your application authenticates against Gurobi's cloud service to get a license token.

The good: Eliminates the license server. Works in containers and serverless environments.

The bad: Still requires network access to Gurobi's auth service at solve time. If Gurobi's service is down (rare, but happens), your optimization pipeline is down. You're still managing license allocation and tracking usage yourself.

Honest assessment: A real improvement over token servers. Still more operational overhead than most teams want.

Option 3: Self-Hosted Serverless

Build your own serverless Gurobi infrastructure. Run Gurobi in Lambda/Cloud Functions with an embedded license.

The good: Full control. No external dependencies at solve time.

The bad: You're building and maintaining infrastructure. Lambda cold starts are brutal for optimization workloads (loading Gurobi adds 2-5 seconds). Container size limits are tight. License embedding requires enterprise-tier Gurobi contracts. You still need to handle scaling, monitoring, and all the ops work.

Honest assessment: Viable if you have platform engineering capacity and specific requirements that demand custom infrastructure. Most OR teams don't and shouldn't.

Option 4: Managed Serverless (Ceris)

Full disclosure: this is what we're building. You submit models to an API, we handle infrastructure, you get results back.

The good: No infrastructure. No license server management (bring your own Gurobi license or use open-source HiGHS/OR-Tools). Pay-per-solve pricing. Switch solvers with a parameter change.

The bad: You're trusting a third party with your models. There's network latency (typically 50-100ms overhead). You lose some low-level Gurobi API features that assume local execution.

Honest assessment: Right for teams who want to focus on modeling, not infrastructure. Wrong for teams with strict data residency requirements or needs for exotic Gurobi features.

"But wait—what about X?"

Let me anticipate some objections.

"Isn't this just Gurobi Cloud with extra steps?"

No. Three key differences:

1. Solver-agnostic. Ceris runs Gurobi, OR-Tools, HiGHS, and (soon) CPLEX through the same API. Gurobi Cloud is Gurobi-only. This matters when you want to benchmark solvers or have cost-sensitive workloads where HiGHS is good enough.

2. Workflow integration. Ceris runs your preprocessing and postprocessing logic alongside the solve. Gurobi Cloud only runs the solver.

3. Pricing model. Ceris is pure consumption pricing. No license tiers, no seat counts, no annual commits. Gurobi Cloud's pricing is... less transparent.

"What about latency? Network round-trips will kill performance."

Let's be specific. For a typical optimization that takes 30 seconds to solve, you're adding maybe 100ms of network overhead. That's 0.3%. For a 5-minute solve, it's 0.03%.

Where latency matters: very fast solves (under 1 second) where you're calling the solver in a tight loop. If you're doing 10,000 sub-second solves, network overhead adds up. For that pattern, you want warm containers or local execution.

Where latency doesn't matter: production optimization runs that take seconds to minutes. Batch processing. Anything where the solve time dominates.

Most production OR workloads fall in the second category. If yours doesn't, serverless might not be the right fit—and I'll tell you that upfront.

"Can I use my existing gurobipy code?"

Mostly yes, with some changes.

Here's traditional gurobipy:

import gurobipy as gp

model = gp.Model()
x = model.addVar(name="x")
y = model.addVar(name="y")
model.setObjective(x + 2*y, GRB.MAXIMIZE)
model.addConstr(x + y <= 10)
model.optimize()

print(f"Optimal: x={x.X}, y={y.X}")

Here's the Ceris equivalent:

import requests

# Export model to MPS format
model = gp.Model()
x = model.addVar(name="x")
y = model.addVar(name="y")
model.setObjective(x + 2*y, GRB.MAXIMIZE)
model.addConstr(x + y <= 10)
model.write("model.mps")

# Submit to Ceris
with open("model.mps") as f:
    response = requests.post("https://api.ceris.fyi/v1/solve", json={
        "model": f.read(),
        "solver": "gurobi",
        "time_limit": 300
    })

result = response.json()
print(f"Optimal: x={result['variables']['x']}, y={result['variables']['y']}")

The pattern: build your model with gurobipy locally, export to MPS/LP format, submit to API. Your modeling code stays the same; the execution changes.

What you lose: callbacks, lazy constraints, some advanced parameter tuning that requires real-time interaction with the solver. For most production workloads, you don't need these. For the workloads that do, you might need a hybrid approach (local for development, API for production batch runs).

"What about data security? I can't send my models to a third party."

Fair concern. Some thoughts:

1. What's actually in an MPS file? Variable names, constraint coefficients, bounds. For most models, this isn't sensitive—it's abstract math. The business context that makes it valuable isn't in the file.

2. What we do with your data: Encrypt in transit (TLS 1.3). Process in isolated compute environments. Delete immediately after solving. Never store models. Never train on your data.

3. If that's not enough: We offer VPC deployment for enterprise customers. Ceris runs in your AWS/Azure account, your data never leaves your network. You still get the DX benefits; you control the data plane.

4. If you're in a regulated industry: We're working toward SOC 2 Type II. We provide audit logs for every solve (timestamp, model hash, solver version, runtime). This is actually better for model risk management than most self-hosted setups.

But look—if your compliance team says no third-party compute, that's a real constraint. Option 3 (self-hosted serverless) might be your path.

"How does pricing actually work?"

Pure consumption. You pay for compute time.

Current pricing: $0.001 per second of solve time (roughly $0.06 per minute, $3.60 per hour).

No license fees. No seat counts. No minimums. If you run zero optimizations in a month, you pay zero.

Comparison math:

Traditional setup:

• Gurobi token server license: ~$12,000/year
• EC2 instance for license server: ~$1,200/year
• DevOps time (conservative): ~$5,000/year equivalent
• Total: ~$18,000/year fixed cost

Ceris:

• 10,000 optimizations/year averaging 2 minutes each = 20,000 minutes
• At $0.06/minute = $1,200/year variable cost

The crossover point depends on your volume. At very high volumes (millions of solve-minutes), traditional licensing becomes cheaper per-solve. But you're also paying that cost whether you use it or not.

For most teams—especially those with spiky workloads—consumption pricing wins.

What Serverless Can't Do (Yet)

I want to be honest about limitations:

Interactive solving. If you need callbacks, incumbent solutions, or real-time progress updates, serverless is awkward. The solve happens on our infrastructure; you can't inject code mid-solve.

Very long solves. Our current timeout is 1 hour. If your model needs to run for 6 hours, you need dedicated compute.

Exotic solver features. Gurobi has hundreds of parameters. We support the common ones. If you need PreQLinearize or NumericFocus tuning, let us know—we can add it—but it's not there by default.

Sub-second solve loops. If you're calling the solver 10,000 times per second in a tight loop, network overhead matters. This is a real limitation of the serverless model.

For these cases, you might need hybrid: Ceris for batch production runs, local Gurobi for development and special cases.

Getting Started

If this sounds useful, here's the path:

1. Request early access at ceris.fyi. We're onboarding teams manually right now—you'll get API credentials and direct support.

2. Try a simple model first. Export an existing model to MPS, submit via curl or Python requests, verify the results match what you get locally.

3. Migrate incrementally. Start with batch workloads or new projects. Keep your existing infrastructure for the stuff that's working.

We include 100 free solve-minutes with every account. Enough to test with real models before committing.

---

The license server isn't going to manage itself out of existence. But you can choose not to manage it. The question is whether the tradeoffs of serverless work for your specific situation.

For most OR teams I talk to, they do. The ones doing exotic solver work or running in highly restricted environments—they need different solutions, and that's fine.

If you're not sure which camp you're in, reach out. I'd rather tell you Ceris isn't the right fit than have you discover it after migration.

→ Request Early Access