What is a policy server? The robot term, defined

A policy server is the program that loads a trained robot policy and hands out actions over a network. The robot runs a small client. That client sends camera frames and joint positions. The server replies with an action chunk, a run of future movement. The arm works through that run while the next one is computed. This page defines the term in plain language. It separates the robot sense from the older access-control sense of the same words. Then it maps the small family of terms around the policy server. It also answers the practical questions: what the big robot stacks ship, whether running one is safe, and where the server machine should sit.

If you read only one sentence, read this one. The thinking stays on the machine that has the memory. The motors stay on the machine that has the arms. The two talk over a wire.

Policy server

The term names a program, not a product class. A policy server loads one trained policy into memory. It waits for requests. It answers each request with movement. The LeRobot documentation from Hugging Face states the shape plainly. Policy servers are wrappers around a trained policy, connecting it to observations arriving from a robot client (LeRobot async inference docs). The server holds the model weights. It runs them on a graphics processor or another accelerator. It returns action data. Nothing on the robot itself is inside the server. It does not drive motors. It does not read cameras. Instead, it receives what the robot sensed. It returns what the robot should do next.

Two details make the idea work in practice. First, the server starts empty in the LeRobot design. The client's first message is called the handshake. It names which policy to load, which checkpoint of it, and which device to run it on. One server can serve different policies to different clients. No restart is needed. Second, the answer is never one movement step. It is a chunk of future actions. The client controls the chunk size. That is what lets a slow network or a slow model hide behind motion already in progress.

One warning about the words themselves. In enterprise software, a policy server means something else. It is a central service that decides who may access what. That is the access-control world of permissions and rules. That sense is older. Outside robotics, it is also more common. A search for the bare phrase today returns gaming sites and network tools before anything about robots. In robot stacks, the word policy means the learned model. This page uses only the robot sense.

Policy

The policy is the trained model itself. It is the artifact a learning run produces. It is a stack of learned numbers. Those numbers map what the robot senses to what the robot should do. Feed it camera images and the current joint positions. Add a plain instruction such as pick up the green cube. It outputs target positions for the joints. The mapping is learned from demonstrations or from practice. No person writes it by hand. That is the difference between a policy and a controller. A controller follows rules a person wrote. A policy imitates behavior it was shown, or improves on it.

The field sorts policies into families. The sorting that matters is memory, because it decides where the policy can run. LeRobot's own hardware guide groups them by need. The small ACT class wants about 2 to 6 GB of video memory. SmolVLA wants about 10 to 16 GB. The pi0 and pi0.5 class wants about 24 to 40 GB. A 24 GB card is already tight at a batch size of one. On this platform those families appear as act, smolvla, and pi05 with its variants. A friendly walkthrough of the model class itself is the VLA explainer on this site.

The word also explains the server's name. The program serves policies the way a web server serves pages. It sits waiting. Its whole job is handing out the output of the thing it holds. The term policy comes from decades of reinforcement learning. There, a policy is the learned mapping from situations to actions. The server part is newer. Robots spent most of their history running everything on one computer. No serving was needed.

Robot client

The robot client is the other half of the pair. It lives next to the hardware. In the LeRobot design, the client owns everything physical. It opens the cameras and talks to the motor bus. It keeps the calibration file. It runs the safety logic. On each cycle it packs what the robot sensed. It sends that bundle to the policy server. It receives the next action chunk back. The client is small on purpose. It needs no graphics processor, no large model weights, and no heavy machine learning tools. A laptop or a small single-board computer next to the arm is enough.

The split of duties has a second benefit, and the stack authors state it themselves. The Isaac-GR00T documentation from NVIDIA lists its reasons for the server-client design. Those reasons are separate compute resources and dependency isolation (Isaac-GR00T policy docs). The robot computer stays free of the large, fragile software that inference needs. Physical Intelligence serves its pi models this way in the openpi project. Its documentation puts the point in plainer words. Running the model remotely helps you avoid dependency hell with robot software (openpi remote inference docs). Swap the model on the server. The robot computer never notices.

The client also owns the tuning that makes motion smooth. In the LeRobot design, the client watches the chunk in hand. When that chunk runs low enough, the client requests the next one. It also blends the tail of the old chunk into the start of the new one. Two settings control this. The chunk size sets how many future actions each answer contains. The threshold sets when to request the next chunk. Set them wrong and you see pauses or jerky joins. Set them for your task and the arm moves smoothly. The network and the model can both be slower than the motors.

Policy deployment

Policy deployment is the act of putting a trained policy somewhere it can serve. It is the step where most robot projects meet real decisions. Training happens in bursts, on whatever heavy machine you can get. Serving happens for hours. The serving machine must be on, trusted, and close enough to the robot in time. Deployment is two matches in one. Match the policy's memory need to a machine that will hold it. Then point the robot client at that machine's address.

There are four shapes a deployment can take. They differ mainly in who owns the machine. The server can run on the same laptop as the client. Every first demo starts that way. It can run on a desktop graphics card in the same room, one wireless hop from the arm. It can run on a rented machine in a data center. That puts the memory on someone else's bill, and adds a real network to the loop. Or it can run as a hosted route. A platform serves the model for you. Your client changes one line, the address. The SO-101 cloud brain guide on this site walks the middle two shapes with real commands. Placement physics by timescale and layer is the Jetson versus cloud guide.

The naming splits by shape, not by essence. A policy server on your own box and a hosted action route are the same split of thinking from moving. What changes is who owns the box. What also changes is the network between the two ends, and how the bill works. The definition above holds for all four shapes. That is why the term survives them all.

The exchange, in one pass

Strip every framework away and one round trip remains. The client sends one frame per camera. It sends the joint positions as numbers. It sends the instruction. The server returns a chunk of future joint targets. On stacks that provide it, the server also returns the normalization numbers. Those say how the targets were scaled for your robot. The exchange below is the whole idea, written as pseudocode.

client -> server:  images (one per camera)
                   joint positions (as numbers)
                   instruction (a plain string)

server -> client:  action chunk (a run of future joint targets)
                   normalization numbers (on stacks that send them)

client:            plays the chunk one row per control tick
                   while requesting the next chunk early

The chunk deserves one careful sentence. One request does not return one movement. It returns a run of future movements. The robot keeps moving through the run it already holds. The next run is computed meanwhile. That is why a round trip of tens of milliseconds does not stall an arm stepping tens of times per second. The failure mode has its own page family. If the wire drops mid-run, the arm runs dry. The connection-loss guides on this site cover it. Normalization numbers are their own trap. The normalization guide covers what goes wrong when they do not travel with the policy.

Every reference stack ships one

The term is not one project's branding. Each of the three reference stacks in open robot learning ships a policy server under that exact name. The differences between them are small and concrete.

Note the ports. They are the first thing that breaks when you switch stacks. The defaults are 8080, 8000, and 5555. None agree. Beyond the reference stacks, the pattern has spread into its own ecosystem. Independent groups publish their own servers. Some load LeRobot policies over gRPC. Some serve models for robot evaluation arenas over WebSocket. Some face the public internet on purpose, with compact wire formats. A standards effort called XPolicyLab treats policy serving as first-class infrastructure. It won a best tool paper award at IROS 2026. It integrates 69 policies as of October 2026 (XPolicyLab). Research has picked the term up too. A January 2026 paper titled VLAgents calls itself a policy server for efficient VLA inference. It benchmarks itself against the default servers that ship with the major stacks.

The spread is the evidence. A research paper, three corporate stacks, a standards effort, and independent tools all use the same two words for the same split. The split is the definition.

Is a policy server safe to run?

The safe form of the rule first. A policy server is safe exactly when only machines you control can reach it. Every reference design in the table above assumes a trusted network. None of them was built to face the public internet with strangers on it.

The field learned this the hard way in 2026. The United States vulnerability database records a critical-rated flaw in the LeRobot async inference pair. Both halves carried it, the policy server and the robot client. The components loaded packaged data from the connection without checking it. The channels had no sign-in and no encryption. An attacker who could reach the server could run code of their choice on the machine holding the graphics processor (NVD, CVE-2026-25874). Versions through 0.5.1 carried it. The flaw class is general, not personal to one project. Another major stack in the table took two similar code-injection reports in 2025. Treat any policy server that unpacks unchecked bytes as a loaded weapon on your network.

The aftermath is a lesson in how fast this layer moves. A repair was proposed in the LeRobot project in early 2026. It swapped the unsafe loading for a safe format. On October 7 2026 a maintainer closed it unmerged. The note said the whole async module is being removed. A new remote inference engine replaces it. That engine merged into the project's main branch on October 12 2026. It ships a command named lerobot-policy-server. We re-checked all of this on October 26 2026, the date on this page. The practical reading for you is simple. Tutorials rank for months while the code under them moves. Before you deploy, check the project's own current docs for the command name and the safe setup. And keep your server off any network you do not control.

Where the server machine sits

Memory first, network second. The policy's family decides the smallest machine that can hold it. Use the memory classes above. Only then does the network question matter. An ACT-class policy serves from almost anything. The laptop running the client is enough. A pi-class policy needs the 24 to 40 GB band. That usually means a desktop card, a rented machine, or a hosted route.

The loop's speed needs settle the rest. Reflexes and safety logic never leave the robot. They belong on the small computer next to the motors. The policy layer tolerates tens to hundreds of milliseconds. The action chunk buys that budget. Reasoning tolerates seconds and can live anywhere. The full placement math, with measured numbers for each layer, is the Jetson versus cloud guide on this site.

The money question has its own page. This one will not spoil it with numbers. A desktop card you run yourself costs the card and the electricity. Renting by the hour turns the purchase into a monthly habit. Several markets exist for hourly cards. A hosted route charges per call instead, against a prepaid balance that stops at zero. The trade between those shapes is worked end to end in the local versus hosted break-even guide. The habits that keep any metered route honest are in the bill shock guide.

The hosted version of the same split

This platform serves robot policies over a hosted action route. The route is the same split described above, with one difference. The address in your client is ours. Camera frames, the instruction, and the robot state go up as one call. An action chunk and the normalization numbers come back. The field-by-field contract is published at the run-action reference. Design notes for the route live on the action route page.

The honest state, dated October 26 2026. The action route and the robot models named on this page are not on the public list. No rate for them renders anywhere today. The models index is the live catalog. A listed row's rate appears on the pricing page. None of that changes the definition above. The definition holds whatever the catalog does. Building a client against the published contract can start today. Sign up and create a key. The client you already have changes one line, the address.

Frequently asked questions

Why use a policy server at all?

Three reasons, in the order the stacks themselves give them. The model gets the memory it needs, on a machine that has it. Your robot computer stays small. The robot software stays free of heavy, fragile inference tools. The openpi authors call this avoiding dependency hell. And the model can be swapped or retrained on the server. Nothing on the robot changes.

Is a policy server the same thing as an inference server?

Close cousins, different emphasis. An inference server in general machine learning serves model predictions to any client. A policy server is the robot-specific form. It serves action chunks to a robot client. It is built around the control loop's timing, not around request volume. In robot stacks the two names often describe the same program. Policy server is the term the robot tools actually use.

Does the robot itself need a graphics processor?

Not for this design. The robot needs a computer able to read cameras, drive the motor bus, and send packets. A laptop or a small board handles that. The graphics processor belongs wherever the policy server lives. One exception is the reflex layer. Fast contact and safety loops belong next to the motors. Those are small programs, not large models.

What is a policy in robotics?

It is the learned model that maps what the robot senses to what it does next. It is trained from demonstrations or practice. It is not written as rules. The word arrives from reinforcement learning. There, a policy has meant exactly that mapping for decades. A policy server is the program that serves that model's answers over a network.

Can someone host the policy server for me?

Yes. That is the hosted route shape, and this platform publishes the contract for one. As of October 26 2026 the robot models here are not on the public list and carry no rendered rate. The live comparison today is between your own machine and a rented one. Rates for listed rows render on the pricing page. The break-even guide above is where that decision gets made.

The term is young enough that no definitional page existed for it. Now one does. The deeper layers each have their own guide on this site, linked above. One covers the wire between server and client. Another covers the placement physics, and another the break-even arithmetic. A fourth walks a specific arm end to end. A definitional companion page, how fast a policy runs, publishes with this wave.

Last verified: 2026-10-26