Search covers 14 link types without owning an index
A search request can limit results by channel, plugin, source, or any of the 14 documented cloud and link categories. PanSou queries Telegram pages and enabled plugins concurrently, then deduplicates, ranks, and groups the returned links. Clients can ask for raw results, merged groups, or both through GET or POST on /api/search. The project is therefore a federation layer over other sites. It does not crawl a durable catalog that remains useful when those sites disappear.
The link-check endpoint covers 9 cloud-drive types and returns states such as valid, bad, locked, unsupported, or uncertain. Per-request proxy settings can be supplied for that check, and its cache is separated by proxy address. Magnet, eD2k, and other search result types are outside the documented validity list. PanSou also has no documented ownership check for a result. A service using it must decide which sources are permitted and how questionable or reported links are removed.
Docker exposes port 8888 while authentication starts off
PanSou defines a 24-hour token lifetime, yet AUTH_ENABLED is false in the supplied image and Compose file. The backend image listens on port 8888; the separate pansou-web image bundles a front end on port 80. Enabling JWT access requires AUTH_USERS, and the README recommends setting AUTH_JWT_SECRET yourself. Open issue 131 concerns the integrated pansou-web image staying public after configuration, so it is a reason to test that image rather than proof of a backend-only failure.
The current config code makes a fixed secret mandatory for a serious deployment. If AUTH_JWT_SECRET is missing, it creates pansou-default-secret- followed by the current Unix timestamp, despite a comment describing a random 32-byte value. Logout only tells the client to delete its JWT, so a copied token remains usable until expiry. The application allows cross-origin requests from any origin. PanSou's Nginx example adds TLS and a 60-requests-per-minute limit, controls the Go service does not supply by default.
What happened when we ran it
Our sandbox installed 68 Go packages in 14 seconds and built commit d46c501 in 56 seconds. Go test completed in 21 seconds with 36 passed and 0 failed out of 36. The checkout contained 233 files, roughly 74,948 lines of source, and occupied 2.9 MB. Every measured step ran in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets.
The repository had 1 CI workflow, a Dockerfile, and a Compose file, with no top-level tests directory. The 36 passing cases live in package files under the source tree, which is normal for Go. Our run did not measure response latency, result freshness, link accuracy, or the availability of Telegram and plugin sites. A clean compiler and test result make code evaluation easier; they cannot certify dozens of external parsers against sites that may change after the commit.
The 4-second response can contain partial plugin results
PanSou's async path uses a 4-second initial response timeout and a 30-second plugin timeout by default. A slower plugin can return what it has quickly, keep working in the background, and update the cache for a later request. The normal cache lifetime is 60 minutes with a 100 MB limit, while the async cache defaults to 1 hour. These are configuration values from the README, not latency results from our sandbox.
Source startup differs between deployment paths. Running from source without ENABLED_PLUGINS activates no plugins, while the supplied Dockerfile and Compose configuration list many by name. That makes the container feel populated immediately, at the cost of sending each query toward a broad collection of independently operated sites. The API allows callers to narrow plugins and channels per request. A sensible deployment begins with a small reviewed list, observes errors and memory, then adds sources individually.
Issue 141 makes the default plugin list an operations job
The issue 141 reporter attributed more than 4 GB of memory and 30,689 requests to the enabled yulinshufa plugin on one deployment. Only 36 requests reportedly returned results, and the source retried failures. The current Docker configuration still includes yulinshufa. We did not reproduce this workload, and the issue has no maintainer reply, so those figures belong to that reporter's instance. They still justify per-plugin request, error, and memory monitoring before copying the full default list into production.
Telegram has separate failure modes. Open issue 129 says a configured proxy produced plugin results while Telegram stayed empty until channels were supplied explicitly. Issue 135 reports blocked t.me resolution affecting 115 results. Both remain open, although their short threads do not isolate a universal cause. The September 2 commit message says several plugins were fixed, and nearby commits add or repair more sources. That pace reflects the job: an upstream domain, page layout, protection layer, or API can change without PanSou changing.
September 2 activity comes without a tagged release
GitHub recorded 14,442 stars, 3,481 forks, and 16 open issues and pull requests on September 2, 2026. Fifteen were issues and 1 was a pull request. The last push was that same day, and a plugin contribution had been merged hours earlier. The queue also contained a referral-link spam issue and long-running community front-end threads, so the combined count should not be read as 16 unresolved bugs. Current commits and issue updates show active use.
The repository has no tagged GitHub release, so adopters must pin a commit or an image digest instead of relying on a versioned release line. commit d46c501 gave us 36 passing tests, and the Docker assets make a trial straightforward. Production is a different decision because authentication needs hardening and every useful source adds an external dependency. PanSou fits a self-hoster who will own that maintenance. It is a poor base for a service promising verified content, stable coverage, or hands-off operation.