# SHKeeper lists its supported coins twice in one section, and the two lists disagree

> vsys-host/shkeeper.io is a self-hosted cryptocurrency payment processor that presents itself as both a gateway and a merchant. Its install path pipes two installers into a shell, its certificate example ships the vendor's own domain, and its container runs a single worker process.

**vsys-host/shkeeper.io** — SHKeeper is a self-hosted and open-source cryptocurrency gateway payment processor. It's integrate with popular CMS, any e-commerce, your own code or product

- Repository: https://github.com/vsys-host/shkeeper.io
- Website: https://shkeeper.io/
- Stars: 629 · Forks: 156
- Language: Python
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/vsys-host-shkeeper-io

## The supported coin list is printed twice and the two copies differ

The section on available assets opens with one sentence listing eleven coins and two stablecoins, with the stablecoins broken out across five networks each. Four lines later the same section starts again with the same lead-in phrase and prints a longer list. The second copy adds Lightning Network as a Bitcoin option, adds four coins the first copy omits entirely including two layer-2 networks, an alternative network and a stablecoin, and adds three more networks to each of the two stablecoins plus a third stablecoin issued on another chain. So the section that answers the first question any integrator asks gives two different answers, with no note that one is more current. It also names the layer-2 networks without saying which coins they carry, which is the part an integrator integrating a specific token will need.

## The certificate example ships the vendor's domain and one of three contact addresses

Automatic TLS is presented in two ways and neither is quite ready to use. The first installs a certificate manager chart at a pinned version, which is the only version pinned anywhere in the setup, so that path will age while the rest floats. It then asks you to write a manifest containing a certificate whose common name and domain list are the vendor's demo host, and whose issuer references a cluster issuer defined lower in the same file. That cluster issuer carries the vendor's own contact address for certificate expiry notices, and its private key secret is named as a placeholder that also has to be changed, which the instructions do not mention since they only tell you to replace the domain and email. The second method writes a proxy configuration file straight into the distribution's server manifests directory, and it uses a third contact address, belonging to the project rather than the vendor, plus a fixed storage path for the account key.

## Installation pipes two installers into a shell and needs a third-party chart

The documented install targets a fresh server running a lightweight Kubernetes distribution and a package manager for Kubernetes charts, tested on one specific Ubuntu release. The first block fetches the distribution's installer and pipes it into a shell, then symlinks its configuration into a root-owned directory, then does the same for the chart manager's installer. Two shell-to-shell pipes before any application code is involved. The second block writes a values file enabling four assets, including a full node for the privacy coin, and chooses a local-path storage class. The third block adds two chart repositories, the project's own hosted on GitHub Pages and a second vendor's, then installs a secret generator from that second vendor before installing the application chart:
```bash
helm install kubernetes-secret-generator mittwald/kubernetes-secret-generator
helm install -f values.yaml shkeeper vsys-host/shkeeper
```
The host is tested on a distribution whose packaged interpreter is older than the one the container image uses.

## One dependency out of nineteen has no version at all

The requirement file pins eighteen packages with exact equality and leaves one bare. The unversioned entry is the cryptography library, which is the one doing the actual cryptographic work in a payment processor, so it is the last place to want a floating resolution. Everything else is pinned tightly enough that the file reads like a lockfile. Two of the pins are worth noticing for what they imply: the ORM layer is held on the pre-2.0 major line while the Flask integration on top of it is from the generation that predates 2.0 support, and the HTTP client is older than everything around it. Read as a set, the requirements map one to one onto the documented surface, with a QR code library for the payment buttons, a metrics client for the metrics endpoint, a Monero-specific library for the full node, a scheduler and a session store for the background work.

## The container runs one worker process with sixteen threads

The image is a single stage that copies the whole build context, installs the requirements, and starts an application server bound to all interfaces on port 5000, which is the same port the documentation tells you to open over plain HTTP before adding TLS. The server configuration is the interesting part. It runs a single worker process with sixteen threads of a threaded worker class, so concurrency is bounded by one interpreter rather than by the machine. Five tuning options sit commented out directly above the bind address, and four of them restate defaults, but two would change behaviour: the request cap that recycles a worker after a number of requests, and its jitter setting. Left commented, a long-lived worker never recycles. Two details in the image are worth flagging as well: the package manager and a version control client are installed in the runtime layer even though the start command needs neither, and the base image's interpreter and the one the package manager installs sit side by side.

## The demo credentials are printed in the document, on a test network

The project publishes a hosted demo so that you can try it without installing anything, and prints the login and password for it directly in the readme, both in bold. The reason that is defensible is stated in the same paragraph: the demo runs on a test network, so nothing of value is behind those credentials. It is still worth knowing before you copy the habit, because the same product is described as serving in two roles at once. The surrounding link block is a mixed bag. Two of the six links point at the project's own endpoints, one is a commit log, one is a tutorial video, one is a knowledge base article, and one is a step-by-step guide to verifying webhook signatures with examples in three languages, hosted in a separate documentation repository rather than in this one.

## No identity or transaction monitoring appears in the feature list, not in a caveat

The feature list has twelve numbered items and the eleventh is the absence of both customer identification and transaction monitoring checks. Everything around it is a mechanism rather than a promise: non-custodial operation, setting your own exchange rates and commissions, crediting an overpayment to a balance, accepting partial payments, routing automatic payouts into a cold wallet, and batched payouts. Non-custodial and the monitoring exemption fit together coherently, since the keys never leave the operator and the screening never happens. What makes it a decision rather than a feature is the pairing with the opening statement that the software acts as both gateway and merchant, which is the position where the operator, not the platform, holds the customer relationship.

## Conclusion

Read the compliance position before the feature list, because the project states that it performs neither identity nor transaction monitoring checks while also acting as the merchant of record, which makes the operator's own obligations the deciding factor rather than a technical detail. On the technical side, expect to finish the setup yourself: the install assumes a Kubernetes distribution and two vendored chart repositories, and the TLS example needs three separate edits before it will issue a certificate for your domain. And if you care about throughput, the container's single worker is the first thing to change.

## FAQ

### How do I install SHKeeper?

The documented path targets a fresh server running a lightweight Kubernetes distribution and a chart manager, tested on one Ubuntu release. You write a values file enabling the assets you want, add two chart repositories, install a secret generator from a second vendor, and then install the project's own chart from a repository hosted on GitHub Pages. The admin interface is then reachable on port 5000 over plain HTTP.

### Does SHKeeper require KYC or AML checks?

Neither appears in the feature list, where the absence of customer identification and transaction monitoring checks is item eleven of twelve. The project also describes itself as serving as both a gateway and a merchant, which is the position where the operator holds the customer relationship.

### Which cryptocurrencies can SHKeeper receive?

Two lists appear in the same section and they differ. The first covers eleven coins plus two stablecoins across five networks each. The second adds a lightning option for Bitcoin, four further coins the first omits, three extra networks for each stablecoin, and a third stablecoin issued on another chain.

### How are SHKeeper payment callbacks authenticated?

With an HMAC signature over the payload. The readme points to a step-by-step verification guide with examples in Python, Flask and PHP, hosted in a separate documentation repository, and recommends using it when writing or updating a custom payment module.

### How is the SHKeeper container configured to serve requests?

The application server is started with a single worker process and sixteen threads of a threaded worker class, bound to all interfaces on port 5000. Five tuning options are present but commented out, including the request cap that would recycle a worker, so a long-lived worker never recycles as shipped.

## Sources

- [License: GPL-3.0](https://github.com/vsys-host/shkeeper.io/blob/main/LICENSE)
- [Project website](https://shkeeper.io/)
- [README](https://github.com/vsys-host/shkeeper.io/blob/main/README.md)
- [Releases](https://github.com/vsys-host/shkeeper.io/releases)
- [vsys-host/shkeeper.io on GitHub](https://github.com/vsys-host/shkeeper.io)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vsys-host-shkeeper-io