Type anything into Google and you're handing over a little more of your search history to a company that already knows more about your habits than you'd probably like. Most people shrug and keep typing. If you run a Proxmox VE homelab, though, you've already got the hardware to do something about it — and it takes less time than you'd think.
SearXNG is a self-hosted search engine that pulls results from dozens of other engines without logging what you searched for or who you are. In this guide, you'll spin one up inside a lightweight LXC container on Proxmox VE, using the community-maintained helper script that most homelab users already rely on for this kind of thing. No Docker Compose files to babysit, no manual dependency wrangling — just a script, a few prompts, and a working search engine in about five minutes.
What You Will Learn
- What SearXNG actually does and why it's different from just "another search bar"
- How to create the LXC container using the community-scripts installer
- Where the configuration file lives and which settings you'll actually want to touch
- How to check that the service is healthy and read its logs when it isn't
- The mistakes almost everyone makes on their first SearXNG install, and how to avoid them
What Is This Feature?
SearXNG is a metasearch engine. Instead of building its own index of the web (which is a genuinely enormous undertaking — ask Google), it sends your query out to a batch of other search engines and news, image, and video sources, then merges the results into one page. No accounts, no search history saved to a server somewhere, no ad profile being built on you in the background.
It runs as its own small web application, listening on a port, that you access through a browser like any other web app. That's where the LXC container comes in. An LXC container is Proxmox's version of lightweight, OS-level virtualization — it shares the host's Linux kernel instead of emulating its own hardware, so it starts in a couple of seconds and uses a fraction of the RAM a full VM would need for the same job. For something like SearXNG, which is really just a Python web app and a small cache database, a container is the right tool. You don't need a whole virtual machine to run one web service.
Why Would You Use It?
The obvious reason is privacy. SearXNG doesn't log your IP address against your queries, doesn't build a profile, and doesn't personalize results based on tracking cookies. If that's the whole reason you're here, great — skip ahead to the prerequisites.
But there's a second, more practical reason homelab users end up running this: public SearXNG instances get rate-limited constantly. Search engines like Google and Bing actively detect and block scraping-style traffic, and a public instance shared by hundreds of strangers trips those defenses fast. You'll hit "rate limited" errors on public instances more often than you'd expect. Running your own means your traffic isn't mixed in with everyone else's, so you get a much more reliable experience.
It's also genuinely useful as a homelab utility. Point your browser's default search engine at it, wire it into a dashboard like Homarr or Homepage if you're already running one, or use it as the backend for other tools that need to search the web programmatically. Once it's running, you'll find reasons to keep it around that have nothing to do with privacy at all.
Prerequisites
Before you start, make sure you have:
- A working Proxmox VE 8.x or 9.x host with root access to the shell (either through the web console or SSH)
- At least 2 vCPU cores and 2048 MB of RAM free for the new container — SearXNG itself is light, but the default script allocation gives it room to breathe under real usage
- 7 GB of free space on whatever storage pool you plan to use for the container's disk
- A network bridge (usually
vmbr0) with either DHCP or a static IP range you can assign from - Basic comfort typing commands into a Linux shell — nothing fancy, but you shouldn't be seeing a terminal for the first time today
You don't need a domain name or SSL certificate to get SearXNG running on your local network. Those only matter later if you decide to expose it outside your LAN, which we'll touch on in the best practices section.
Step-by-Step Tutorial
Step 1: Open the Proxmox shell
Log into the Proxmox web interface, click your node in the left-hand tree, and open Shell from the top toolbar. SSHing in directly works just as well if you'd rather use your own terminal.
Step 2: Run the SearXNG install script
Paste this command and press Enter:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/searxng.sh)"This pulls a script from the community-scripts project — a widely used, open-source collection of install scripts for exactly this kind of one-app-per-container setup — and runs it. It builds a new LXC container from scratch, installs Debian 13 inside it, and configures SearXNG automatically.
Step 3: Choose Default or Advanced settings
The script asks whether you want Default or Advanced installation settings. Default gives you a Debian 13 container with 2 CPU cores, 2048 MB of RAM, and a 7 GB disk, using DHCP for networking. For a first install, take the default — you can always bump the resources up later from the Proxmox web UI without reinstalling anything.
If you pick Advanced, you'll get prompted for a static IP, custom hostname, VMID, and storage target instead of letting the script choose for you. Useful if you're picky about IP addressing in your homelab, unnecessary if you're not.
Step 4: Wait for the install to finish
This takes roughly two to four minutes depending on your storage speed and internet connection. The script downloads the Debian template if it isn't cached locally already, creates the container, installs Python, sets up a virtual environment, and configures SearXNG plus its Valkey cache (an open-source, Redis-compatible in-memory database SearXNG uses to cache search results briefly, which speeds up repeat queries).
When it's done, the script prints the container's IP address directly in the terminal. Write it down — you'll need it in the next step.
Step 5: Open SearXNG in your browser
Go to http://<container-ip>:8888 in a browser on the same network. You should see the SearXNG search box immediately, no login screen involved. Type a test query and confirm you're getting results back from multiple engines.
If the page won't load at all, jump to the Troubleshooting section below before assuming something's badly broken — nine times out of ten it's a firewall or networking hiccup, not a failed install.
Step 6: Set a real secret key
Every fresh SearXNG install ships with a default, publicly known secret key used to sign session cookies. It needs to change before you rely on this instance for anything. From the Proxmox shell, enter the container:
pct enter 100(Replace 100 with your container's actual VMID — you'll see it in the Proxmox web UI under the node's container list.)
Generate a new key and drop it into the config:
sed -i "s/ultrasecretkey/$(openssl rand -hex 32)/g" /etc/searxng/settings.yml
systemctl restart searxngThat one-liner finds the placeholder key in settings.yml and swaps it for a randomly generated 32-byte hex string, then restarts the service to pick up the change.
Commands Explained
A quick rundown of everything you just typed, so it's not just muscle memory:
| Command | What it does |
|---|---|
bash -c "$(curl -fsSL ...)" | Downloads the install script and runs it immediately, without saving a copy to disk first |
pct enter 100 | Drops you into an interactive shell inside container 100, as if you'd SSH'd into it directly |
pct list | Shows every LXC container on the host along with its VMID, status, and name — handy if you forgot the ID |
systemctl status searxng | Reports whether the SearXNG service is running, and shows the last few log lines if it crashed |
systemctl restart searxng | Restarts the service so it picks up any changes you made to settings.yml |
journalctl -u searxng -f | Streams the live log for the SearXNG service — the -f follows new lines as they're written, like tail -f |
Common Errors
"This request has been rate limited" shows up when one of SearXNG's upstream engines — usually Google or Bing — detects scraping-style traffic from your container's IP and temporarily blocks it. This isn't a bug in your install. It happens to public instances constantly and occasionally to self-hosted ones too, especially if your ISP's IP range has a bad reputation. It usually clears on its own within a few minutes to a few hours.
searxng.service fails to start immediately after install. Nine times out of ten this is a race condition where the service tried to start before Valkey was ready. Run systemctl restart searxng once, manually, and it almost always comes up clean the second time.
The web UI loads but every search returns zero results. Check that the container actually has outbound internet access — SearXNG needs to reach the engines it's querying. From inside the container, curl -I https://www.google.com should return an HTTP response. If it times out, the problem is your bridge or firewall configuration, not SearXNG.
Can't reach port 8888 from another device on the network. Check whether the Proxmox VE firewall is enabled on the container or the node under Datacenter → Firewall. It's off by default on fresh installs, but if you've hardened your cluster already, you may need an explicit allow rule for TCP 8888.
Troubleshooting
Start with the basics before you assume anything's actually broken:
- Run
systemctl status searxnginside the container. "active (running)" in green means the service itself is fine — your problem is probably networking, not SearXNG. - Check
journalctl -u searxng --no-pager -n 50for the last 50 log lines if the service keeps crashing. Python tracebacks here almost always point straight at the actual problem — a malformed line insettings.ymlis the usual culprit after manual edits. - Confirm Valkey is running with
systemctl status valkey. If it's down, SearXNG's caching layer won't work and searches will feel noticeably slower, even if results still come back. - From the Proxmox host,
pct config 100(swap in your VMID) shows you the container's network configuration, so you can confirm it actually got an IP address from DHCP.
If you edited settings.yml by hand and the service won't start at all, YAML indentation is almost certainly the issue — it's whitespace-sensitive, and a single misplaced space will break the whole file. Undo your last change and restart before digging further.
Best Practices
Change the secret key before you do anything else. It takes ten seconds and closes an obvious gap.
Don't forward port 8888 straight to the internet on your router. If you want SearXNG reachable outside your home network, put a reverse proxy in front of it with HTTPS and, ideally, some form of authentication. An open, unauthenticated search proxy on the public internet is a pretty easy pattern for aggressive traffic to find sooner or later.
Trim the engine list to what you actually use. SearXNG ships with dozens of enabled engines by default, and querying all of them on every search is slower and more likely to trip a rate limit on at least one. Disabling the ones you never use — image search engines you don't care about, regional engines outside your language — makes results come back faster.
Take a snapshot of the container before major config changes. It's a container, so snapshots are close to instant, and rolling back a bad settings.yml edit takes seconds instead of a manual rebuild.
Keep the OS packages inside the container current with a routine apt update && apt upgrade. The community script doesn't do this for you automatically, and Debian security patches still matter even inside a small utility container.
Frequently Asked Questions
Is it legal to run SearXNG?
Yes. It's open-source software that queries public search engines the same way a browser would, just aggregated. It's not scraping anything you couldn't access manually yourself.
Does SearXNG log my searches?
Not by default. There's no database of past queries tied to your identity, and it doesn't set tracking cookies the way commercial search engines do.
Can more than one person in my house use the same instance?
Yes, without any extra setup. It's just a web server — anyone on your network can point a browser at the container's IP and search from it simultaneously.
Will it work on my phone?
As long as your phone is on the same network (or connected through something like Tailscale or a VPN back into your homelab), yes — it's just a normal web page.
Can I set it as my browser's default search engine?
Yes. Most browsers let you add a custom search engine by URL. SearXNG supports a search query parameter you can plug straight into that field, so typing in your address bar searches your own instance instead of Google.
Do I need a domain name to use this?
No, not for local network use. You only need one if you want to reach it securely from outside your home, through a reverse proxy with a real SSL certificate.
Conclusion
You've now got a working, private search engine running in a container that uses a fraction of the resources a full VM would need for the same job. It took one script, a couple of prompts, and a config tweak for the secret key — not exactly a weekend project.
From here, the natural next steps are trimming the engine list to your liking, wiring it into your homelab dashboard if you run one, and deciding whether it's worth exposing outside your network behind a proper reverse proxy. None of that is urgent. For now, open a new tab, point it at your container's IP, and enjoy searching the web without something on the other end quietly taking notes.