This product was not featured by Product Hunt yet. It will not be visible on their landing page and won't be ranked (cannot win product of the day regardless of upvotes).
Product upvotes vs the next 3
Waiting for data. Loading
Product comments vs the next 3
Waiting for data. Loading
Product upvote speed vs the next 3
Waiting for data. Loading
Product upvotes and comments
Waiting for data. Loading
Product vs the next 3
Loading
tethered 1.0
A firewall inside your Python app, in one line
List the servers your app may talk to, in one line of Python. Any other connection Python makes is refused before it opens, whether it comes from your own code, a dependency or code an AI wrote. Free and open source, with no proxy to run.
Hi Product Hunt! I'm Sergii, and I build tethered. It was here in March as version 0.1. This is 1.0, and most of what follows is new since then.
Your code, your dependencies and code an AI assistant wrote all run in one Python process, and any of them can open a connection to a host you never meant it to reach: a logging library that phones home, a hijacked release that sends your environment variables somewhere, a script an agent wrote that calls an API nobody expected. Firewalls, network policies and egress proxies can stop that, but they take a platform team, a separate service or admin rights.
From then on, every connection made through Python's socket layer is checked against that list before it opens, and anything else raises tethered.EgressBlocked. For the libraries that resolve through Python (requests, httpx, urllib3, aiohttp), the lookup of a name that is not on the list is refused before it is sent. It works from inside the process, through Python's audit hooks (PEP 578): no proxy, no sidecar, no monkey-patching, no runtime dependencies.
What it does
Narrows one code path. tethered.scope(allow=[...]), as a decorator or a with block, holds a request handler, a job or a library call to the hosts it needs. A scope only narrows the process policy, never widens it.
Follows your workers. multiprocessing and ProcessPoolExecutor workers, gunicorn and uvicorn workers and subprocess.run([sys.executable, ...]) start with the policy in place. Other programs are logged, or refused with external_subprocess_policy="block".
Rolls out without surprises. uv run python -m tethered check lists what it would refuse or not see in your environment, and changes nothing. Then enforce it in your test suite, watch production with log_only=True, enforce, and lock.
Locks. With locked=True, replacing or switching off the policy takes a token, and monkey-patching tethered or swapping its policy is detected and fails closed.
Measured. uvicorn, gunicorn, Django, Celery and 19 more servers, frameworks, task queues and pools, and 70 client-library arrangements, each run in containers without a network, with every connection counted where it arrives.
What it isn't
tethered is not a sandbox. It sees what goes through Python's socket module. Code that goes below it (ctypes, a C extension making its own system calls) and libraries that connect in their own C code (psycopg2, pycurl, grpcio) are not checked, and the compatibility page lists what was measured, those included. Under asyncio it needs the standard event loop: next to uvloop it refuses to run rather than run unenforced. Where you need a guarantee, combine it with a control below Python, such as an egress proxy or a network policy.
It's free and open source (MIT):
uv add tethered
I'd love your feedback. Where would an allow list have caught something for you? And which server or client library should the compatibility suites run next?
tethered 1.0 was submitted on Product Hunt and earned 4 upvotes and 2 comments, placing #99 on the daily leaderboard. List the servers your app may talk to, in one line of Python. Any other connection Python makes is refused before it opens, whether it comes from your own code, a dependency or code an AI wrote. Free and open source, with no proxy to run.
On the analytics side, tethered 1.0 competes within Open Source, Developer Tools, GitHub and Security — topics that collectively have 635.8k followers on Product Hunt. The dashboard above tracks how tethered 1.0 performed against the three products that launched closest to it on the same day.
Who hunted tethered 1.0?
tethered 1.0 was hunted by Sergii Shcherbak. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Sergii Shcherbak
Hi Product Hunt! I'm Sergii, and I build tethered. It was here in March as version 0.1. This is 1.0, and most of what follows is new since then.
Your code, your dependencies and code an AI assistant wrote all run in one Python process, and any of them can open a connection to a host you never meant it to reach: a logging library that phones home, a hijacked release that sends your environment variables somewhere, a script an agent wrote that calls an API nobody expected. Firewalls, network policies and egress proxies can stop that, but they take a platform team, a separate service or admin rights.
tethered takes one line of Python, for example:
From then on, every connection made through Python's socket layer is checked against that list before it opens, and anything else raises tethered.EgressBlocked. For the libraries that resolve through Python (requests, httpx, urllib3, aiohttp), the lookup of a name that is not on the list is refused before it is sent. It works from inside the process, through Python's audit hooks (PEP 578): no proxy, no sidecar, no monkey-patching, no runtime dependencies.
What it does
Narrows one code path. tethered.scope(allow=[...]), as a decorator or a with block, holds a request handler, a job or a library call to the hosts it needs. A scope only narrows the process policy, never widens it.
Follows your workers. multiprocessing and ProcessPoolExecutor workers, gunicorn and uvicorn workers and subprocess.run([sys.executable, ...]) start with the policy in place. Other programs are logged, or refused with external_subprocess_policy="block".
Rolls out without surprises. uv run python -m tethered check lists what it would refuse or not see in your environment, and changes nothing. Then enforce it in your test suite, watch production with log_only=True, enforce, and lock.
Locks. With locked=True, replacing or switching off the policy takes a token, and monkey-patching tethered or swapping its policy is detected and fails closed.
Measured. uvicorn, gunicorn, Django, Celery and 19 more servers, frameworks, task queues and pools, and 70 client-library arrangements, each run in containers without a network, with every connection counted where it arrives.
What it isn't
tethered is not a sandbox. It sees what goes through Python's socket module. Code that goes below it (ctypes, a C extension making its own system calls) and libraries that connect in their own C code (psycopg2, pycurl, grpcio) are not checked, and the compatibility page lists what was measured, those included. Under asyncio it needs the standard event loop: next to uvloop it refuses to run rather than run unenforced. Where you need a guarantee, combine it with a control below Python, such as an egress proxy or a network policy.
It's free and open source (MIT):
I'd love your feedback. Where would an allow list have caught something for you? And which server or client library should the compatibility suites run next?
GitHub: https://github.com/shcherbak-ai/tethered
Docs: https://tethered.shcherbak.ai