Postman Silently Auto-Installs AI Plugins And Attempts To Share All API Data

Let’s be honest: for years, Postman has been the undisputed king of API testing. Whether you were building a web app, integrating a third-party service, or poking around the APIs of your smart home devices, Postman was the tool you opened. It was reliable, feature-rich, and easy to use.

But recently, something changed. Something that has the developer and homelab communities up in arms. Postman has started silently auto-installing AI plugins and, even worse, attempting to share your API data with their cloud-based AI models without explicit, informed consent.

If you’re running a homelab, testing local AI models, or interacting with internal services like Proxmox, Home Assistant, or Nextcloud, this is a massive red flag. In this article, we’re going to break down exactly what Postman is doing, why it’s dangerous for homelabbers, and how you can replace it with privacy-respecting, self-hosted, or local-first alternatives.

What Exactly Did Postman Do?

To understand the uproar, we need to look at what Postman has been doing behind the scenes. Postman introduced “Postbot,” an AI assistant designed to help you write API tests, generate documentation, and debug requests. Sounds helpful, right?

The problem isn’t the existence of Postbot. The problem is how it was deployed and what it does with your data.

Silent AI Plugin Installation

Users started reporting that Postman was silently auto-installing AI-related plugins and features in the background. Instead of presenting a clear opt-in prompt, these features were quietly enabled during app updates. In the world of software, silently installing background services or plugins is a huge violation of trust. When software acts like malware to install its own features, it’s time to reevaluate the software.

The most alarming part of this debacle is the data sharing. When you use an API client, you are sending highly sensitive data. This includes:

  • Bearer tokens and API keys: Authentication credentials for your services.
  • Request payloads: The actual data you are sending to your servers.
  • Response payloads: The data your servers send back.
  • Internal IP addresses: The URLs of your private homelab services.

Users discovered that Postman was sending context from their API requests to external AI servers to “assist” the Postbot. Even if you didn’t explicitly ask Postbot for help, the AI context was being gathered and prepped for transmission. While Postman claims they don’t store this data long-term, the fact that your internal homelab API traffic is being piped to a third-party cloud AI without a giant, unmissable “I Consent” button is unacceptable.

Why This Matters for the Homelab Community

If you’re just testing a public API like the GitHub API or a weather service, sending your request data to an AI might not seem like a big deal. But for homelabbers, the stakes are much higher.

Leaking Internal Network Topologies

Homelabs are private by design. We use internal IP ranges (like 10.0.0.x or 192.168.x.x), custom DNS names (like proxmox.local or nas.lan), and self-signed certificates. When your API client decides to send the URL of your request to an external AI server, you are effectively handing over a map of your internal network.

Exposing Home Assistant and Proxmox Tokens

Many of us use API clients to interact with Home Assistant to trigger automations, or with Proxmox to manage virtual machines. To do this, you need long-lived access tokens. If these tokens are included in the headers of a request that gets sent to an external AI for “context analysis,” you have just handed the keys to your digital kingdom to a third party.

Compromising Local AI Workflows

Since this is Self-Hosted Tech, many of you are running local LLMs using Ollama, vLLM, or text-generation-webui. You might be using an API client to test the /api/generate endpoints of your local models. If Postman intercepts the prompts you are sending to your local, private, offline AI and sends them to Postman’s cloud AI, the entire purpose of running a local, private LLM is defeated.

The Fix: Local-First and Self-Hosted Alternatives

We don’t need to put up with software that phones home. The beauty of the self-hosting and open-source communities is that there is always an alternative. When it comes to API clients, we have two fantastic options that respect your privacy: Bruno and Hoppscotch.

Bruno: The Local-First Champion

Bruno is a rapidly growing, open-source API client that is directly challenging Postman. The core philosophy of Bruno is simple: your data stays on your device. There is no cloud sync, no telemetry, and absolutely no silent AI plugins.

Bruno stores your collections as plain text files in a folder on your hard drive. This means you can version control your API collections using Git, making it perfect for developers and homelabbers who want to keep track of changes over time.

Hoppscotch: The Self-Hosted Web Client

If you prefer the web-based interface of Postman (which runs as a packaged web app), Hoppscotch is the ultimate self-hosted alternative. Hoppscotch is an open-source, lightweight, web-based API testing suite. Because it is open-source, you can spin up a Docker container and run it entirely on your own hardware.

Practical Walkthrough: Self-Hosting Hoppscotch in Your Homelab

Let’s get practical. We’re going to self-host Hoppscotch using Docker. This will give you a completely private, web-based API client that you can access from any browser on your local network, safe in the knowledge that no data is ever leaving your homelab.

Prerequisites

  • A machine running Docker and Docker Compose (like a Raspberry Pi, an NUC, or a Proxmox LXC).
  • Basic familiarity with the command line.

Step 1: Set Up the Docker Compose File

Create a new directory for your Hoppscotch deployment and navigate into it:

1
2

mkdir ~/hoppscotch
cd ~/hoppscotch

Create a docker-compose.yml file:

1

nano docker-compose.yml

Paste the following configuration into the file. Hoppscotch is a frontend application, so the setup is incredibly straightforward. We will map it to port 3000 on our host.

1
2
3
4
5
6
7
8
9

version: '3.8'

services:
  hoppscotch:
    image: hoppscotch/hoppscotch:latest
    container_name: hoppscotch
    ports:
      - "3000:3000"
    restart: unless-stopped

Save and exit the file (Ctrl+O, Enter, Ctrl+X in nano).

Step 2: Launch Hoppscotch

Bring up the container using Docker Compose:

1

docker-compose up -d

Once the container is running, open your web browser and navigate to http://<your-server-ip>:3000. You should be greeted by the Hoppscotch interface.

Notice something missing? There are no AI assistants prompting you to share your data. There are no background plugins downloading. It’s just a clean, fast, and completely private API client.

Step 3: Importing Your Postman Collections

You don’t have to start from scratch. You can easily migrate your existing Postman data to Hoppscotch.

  1. Open Postman (one last time).
  2. Click on your Collection, click the three dots (...), and select Export.
  3. Choose Collection v2.1 (the standard format) and save the JSON file to your computer.
  4. In your self-hosted Hoppscotch instance, click on Collections in the left sidebar.
  5. Click the Import button (usually an arrow icon at the top or bottom of the collections panel).
  6. Select the JSON file you exported from Postman.

Your requests, headers, and history will be imported. Now you can safely delete Postman from your machine.

Step 4: Testing an Internal API (Example)

Let’s test a local API to prove how secure this setup is. We’ll make a simple GET request to a Home Assistant instance.

  1. In Hoppscotch, change the HTTP method to GET.
  2. In the URL bar, enter your internal Home Assistant API endpoint, for example: http://homeassistant.local:8123/api/states/light.living_room.
  3. Go to the Headers tab.
  4. Add a new header:
    • Key: Authorization
    • Value: Bearer YOUR_LONG_LIVED_ACCESS_TOKEN
    • Key: Content-Type
    • Value: application/json
  5. Click the Send button.

You will get the JSON response from your Home Assistant instance detailing the state of your living room light.

Because you are using a self-hosted Hoppscotch instance, the request goes directly from your browser, to your local Home Assistant, and back. Your bearer token and your internal DNS name (homeassistant.local) never touch a third-party server.

Best Practices for Securing Your API Workflow

Switching to Bruno or Hoppscotch is a great first step, but securing your homelab’s API testing workflow requires a few more good habits:

  • Use Environment Variables: Never hardcode your API keys directly into your requests. Both Bruno and Hoppscotch support environments. Create a “Local Homelab” environment and store your tokens as variables (e.g., {{HA_TOKEN}}). This keeps your secrets separated from your request definitions.
  • Audit Your Tools Regularly: The Postman situation is a reminder that software can change ownership and philosophies overnight. Make a habit of checking the network traffic of your development tools using tools like Pi-hole or AdGuard Home. If you see your API client making unexpected DNS requests to AI servers, it’s time to look for an alternative.
  • Restrict API Tokens: When generating tokens for Home Assistant, Proxmox, or your local LLMs, always use the principle of least privilege. If a token is only meant to read data, don’t give it write permissions. That way, even if a token is somehow leaked, the blast radius is minimized.
  • Keep Your Alternatives Open Source: By choosing tools like Bruno and Hoppscotch, you are relying on community-driven software. The code is public, meaning if a developer ever tried to sneak in telemetry or AI data-sharing, the community would spot it in a pull request before it ever reached your machine.

Summary

The recent news that Postman is silently auto-installing AI plugins and attempting to share API data is a stark reminder of why the self-hosting community exists. We build our homelabs to take control of our data, to keep our network topologies private, and to run local AI without the prying eyes of cloud corporations.

When a trusted developer tool turns into a data-harvesting liability, it’s time to move on. By migrating to local-first tools like Bruno or self-hosting your own API client with Hoppscotch, you ensure that your internal tokens, IP addresses, and API payloads remain exactly where they belong: inside your homelab.

Call to Action: Have you made the switch away from Postman yet? What are you using to test your homelab APIs? Let us know in the comments below! If you found this guide helpful, make sure to subscribe to the Self-Hosted Tech YouTube channel and bookmark the blog for more practical guides on securing your homelab and running local AI. Stay private, stay self-hosted!