Run the Agents Locally | WarpStream ⌘Ctrlk WarpStream.comSlackDiscordContact UsCreate AccountMore GitBook Assistant Good evening I'm here to help you with the docs. What is this page about?What should I read next?Can you give an example? ⌘Ctrli AI Based on your context Send Overview Introduction Architecture Change Log Getting Started Install the WarpStream Agent / CLI Run the Agents Locally "Hello World" for Apache Kafka Agent Setup Deploy the Agents Object Storage Configuration Set up Monitoring Infrastructure as Code Kafka Configure Clients Manage Security Manage Connectors Deploy (advanced) Reference Benchmark Orbit (Cluster Linking) Tableflow Tableflow Setup Monitoring Tableflow Iceberg REST Catalog Integrate With Query Engines and External Catalogs API Reference Schema Registry Setup Enforce Schemas Schema Linking Manage Security Reference Billing Audit Logs Events MCP Server Accessing the Confluent Support Portal Security and Privacy Considerations Manage Console Access Secrets Overview API Reference CLI Reference Integrations Dedicated Control Plane Cells and Release Windows Control Plane Private Connectivity Deprecation Policy Powered by GitBook On this page For the complete documentation index, see llms.txt. This page is also available as Markdown. Ask On this page Getting Started Run the Agents Locally Instructions on how to run the WarpStream Agent locally for testing / development purposes. First, install the WarpStream Agent for your platform. Playground vs. Local There are two ways to run WarpStream locally: playground mode local mode playground mode is designed for interactive local development. It signs up for a temporary WarpStream account that is valid for a few hours, starts a local Agent with an embedded Kafka cluster, Schema Registry cluster, and Tableflow cluster, and uses the real hosted WarpStream control plane so that you have full access to WarpStream's featureset, API, and UI to explore as much of the product as possible. If you just want to test something manually, or explore the product, this is the best option. local mode is designed for non-interactive local development like automated CI environments. Unlike playground mode, local mode has no dependency on WarpStream's hosted control plane and instead uses a fake in-memory control plane in the Agent binary itself. This makes it suitable for CI environments where hundreds or even thousands of ephemeral WarpStream clusters need to be spawned simultaneously without being subjected to ratelimits. Both playground and local mode store data in memory, so any data written will no longer be accessible once the process exits. They're also heavily ratelimited in terms of the amount of Kafka traffic they can handle and are not suitable at all for benchmarking. Docker Playground Local AskCopy docker run -p 8080 -p 9092:9092 -p 9094:9094 public.ecr.aws/warpstream-labs/warpstream_agent:latest playground AskCopy docker run -p 8080 -p 9092:9092 -p 9094:9094 public.ecr.aws/warpstream-labs/warpstream_agent:latest local Once the docker container is running, there will be a Kafka TCP server listening on port 9092 and a Schema Registry HTTP server listening on port 9094. This means you're ready to run any application locally that expects to connect to Kafka, and it'll connect to WarpStream instead if you set the bootstrap URL to localhost:9092. You can also replace the URL of your schema registry clients to localhost:9094 and it'll connect to WarpStream's Schema Registry instead. If you encounter any problems connecting an application running outside of Docker to the WarpStream agent running inside of Docker, follow our instructions below for diagnosing connection issues. Standalone Binary Alternatively, if you installed the standalone WarpStream Agent binary and it is in your PATH, you can just run: Playground Local Both playground and local mode store data in memory, so any data written will no longer be accessible once the process exits. Once that completes, run the following command to test the Kafka connection: If that succeeds, then you're ready to run any application locally that expects to connect to Apache Kafka, and it'll connect to WarpStream instead if you set the bootstrap URL to localhost:9092. If the diagnostic command returns an error, follow the provided instructions to diagnose and fix it. To test the Schema Registry connection, you can send a request to the server with curl as follows: If you receive a valid response, such as {"id":1}, then you're ready to run any application locally that expects to connect to a schema registry by replacing schema registry URL with localhost:9094. Diagnosing Connection Issues The WarpStream Agent binary ships with a utility for diagnosing connection issues. However, diagnosing connection issues cannot be done in a general purpose manner from within a Docker container. Therefore even if you're running the Agent in a Docker container locally, you'll need to follow our "Installation Script" Agent installation instructions to install the raw WarpStream Agent binary locally before proceeding. Once the binary is installed, run the following command to test the connection: If that succeeds, then you're ready to run any application locally that expects to connect to Apache Kafka, and it'll connect to WarpStream instead if you set the bootstrap URL to localhost:9092. If the diagnostic command returns an error, follow the provided instructions to diagnose and fix. PreviousInstall the WarpStream Agent / CLINext"Hello World" for Apache Kafka Last updated 1 month ago Was this helpful? Privacy Cookie Settings Playground vs. Local Docker Standalone Binary Diagnosing Connection Issues AskCopy warpstream playground AskCopy warpstream local AskCopy warpstream kcmd -type diagnose-connection -bootstrap-host localhost -bootstrap-port 9092 AskCopy curl -X POST "http://localhost:9094/subjects/foo/versions" \ -H "Content-Type: application/json" \ -d '{"schema": "{\"type\":\"long\"}"}' AskCopy warpstream kcmd -type diagnose-connection -bootstrap-host localhost -bootstrap-port 9092