Expose
Publish a private app.
Give a local service a public HTTPS address without opening an inbound port.
See it happen →Private networks, made reachable
Your private world, connected.
Link your homelab, VPS, and laptop in one private mesh. Publish an app on a public HTTPS address, put it behind a login, and know the moment something breaks.
- Rootless daemon
- Outbound-only
- Relay + direct paths
homelabonline
grafanagrafana/grafana:latest:3000grafana · :3000
jellyfinjellyfin/jellyfin:latest:8096
grafana-alice.user.dednets.com
healthy100% · 24 h
Publish grafana : 3000Publish
DedNets edgeTLS · routing
grafana-alice.user.dednets.com
Issuing a certificate…200 OK · 41 ms
No inbound port openedoutbound-only daemon
1Your homelab's containers show up, one chip per port.
2Click a free port and name the app.
3It gets a public HTTPS hostname right away.
4The first visit gets a TLS certificate on the spot.
5Traffic rides the daemon's outbound connection.
6Live, and nothing opened on your router.
One daemon, four jobs
Reach anything, from anywhere.
One lightweight daemon handles the paths. You choose what meets the internet, who gets in, and what you want to hear about.
Protect
Keep strangers out.
Put a DedNets sign-in in front of an app, and a browser check in front of bots.
See who gets in →Gateway
Bring your own ingress.
Use a personal VPS, domain, and IP to publish raw TCP or UDP on any port.
See a gateway →Monitor
Know when it breaks.
Uptime checks, cron watchdogs and signals from your own scripts, in one alert feed.
See an alert →Protect
Only the people you allow get in.
Turn on app authentication and DedNets itself becomes the front door: a visitor has to sign in and be on your list. Everyone else is stopped at the edge and never reaches your machine. A browser check in front of public apps keeps scripted traffic out too.
- ✓A sign-in gate per app
- ✓A browser check against bots
- ✓Refused requests never reach your host
>_script · no JS◎a browser?a visitorccarolbbob
blog-alice.user.dednets.comdash-alice.user.dednets.com
$ curl blog-alice.user.dednets.com403 ForbiddenThe check runs in JavaScript. A script never passes.
Checking your browser…
200 OK
Sign in to open dashpublished by aliceSign in
You don't have accessSigned in as carolSign in as someone else
200 OK
DedNets edge
Browser checkblog · public403clearedchecking
Sign-in gatedash · alice's listonsign innot on listbob allowed
Stopped at the edge123
alice's homelab
Requests receivednone yetbloga browserdashX-DedNets-User: bobbob
0 refused requests reached the homelaball 3 stopped at the DedNets edge
1A script can't run the browser check: 403 at the edge.
2A real browser solves it in under a second and gets in.
3dash has a sign-in gate: sign in to DedNets first.
4carol signs in, but she is not on alice's list.
5bob is on the list, so his request goes through.
6Refused requests never reached alice's machine.
Bring your own ingress
Use the edge you already own.
Run DedNets in gateway mode on your VPS and carry raw TCP or UDP to a private machine on your own domain, IP, and ports, even below 1024. Published ports keep working through a Console outage.
- ✓Game servers, databases, DNS: any port
- ✓Direct path when it can, relay when it must
- ✓Keeps serving if the Console is down
player
mc.example.comvpsyour gateway
203.0.113.7:25565 tcpactive
via relaypunching…direct path
Consoleonlineoffline
console.dednets.comhomelab
minecraft:25565
stays where it runsDedNets relay
Published port kept workingthrough the Console outage
1A player joins mc.example.com:25565.
2It lands on your VPS gateway: your IP, your port.
3The gateway forwards it over the mesh, relay first.
4Then a hole-punched direct path takes over.
5The game is on, packets flowing both ways.
6The Console goes offline.
7Traffic keeps flowing. The player never noticed.
Request logs
See what your app is actually serving.
Turn on a short log for one app and watch requests arrive live: path, status, timing, and the visitor's network. Query strings, bodies, cookies and full IP addresses are never stored, and turning it off deletes everything.
- ✓A live tail, kept for 24 hours
- ✓Find the 502 behind a failing webhook
- ✓Off for every app until you turn it on
shopshop-alice.user.dednets.comonline
Request logliveNothing is being recordedRecording every requestoffon
Turn this on to keep a short log of the requests our edge serves for this app - what was asked for, what we answered, and how long it took.
RequestAnswerTookClient network
POST/webhook/stripe502no answer3ms203.0.113.0/24
GET/assets/logo.svg3042ms198.51.100.0/24
GET/products20018ms198.51.100.0/24
GET/assets/app.css2004ms198.51.100.0/24
GET/20012ms198.51.100.0/24
Deleted after 24 hours, and only the newest 5,000 are kept. Turning this off deletes them all right away.
no answerOur edge could not reach your app: the 502 your visitor saw.
POST /webhook/stripe502 · no answer
Client network203.0.113.0/24
Query stringnot stored
Body, cookies, headersnot stored
Record requests for shop?
- the hostname, method and path
- the status, how long it took, the bytes sent
- the visitor's network, like 203.0.113.0/24
- the browser's user agent
1Request logs are off for every app until you turn them on.
2First you read exactly what gets stored, then start.
3Every request through the edge arrives as a row, live.
4Path, status, timing and the visitor's network.
5A webhook gets a 502: the edge could not reach the app.
6Only a network prefix is kept, never the query string.
7Kept 24 hours; turning it off deletes every row.
Monitoring
Know the moment something breaks.
Three ways to watch, one alert feed. You hear about it once when it breaks, and once when it recovers.
shophttps://shop.example.com/healthupdown
DedNets edgeshop.example.com
GET /health200 OK84 msHTTP 503 Service Unavailable (want 200-299)HTTP 5033 failed in a row
criticaluptime · shopNeeds you nowconfirmedOutage · 2 min · 4 checksHTTP 503
Monitor down: shopConsole · Telegram · phone
Monitor recovered: shopConsole · Telegram · phone
1The edge probes your URL every 30 s.
2A probe gets a 503: it shows down.
3Three failures in a row: an alert.
4One notification reaches you.
5Two good checks: up, one all-clear.
6The outage is logged with its cause.
Uptime checks
Probe a URL or a TCP port from our edge or from one of your own hosts, every 30 seconds to an hour.
nightly-backupNightly backup · 24 h period · 1 h graceuplatedown
backup jobConsole
Night 1GET /api/v0/wd/wd…200 okNight 2GET /api/v0/wd/wd…200 okNight 3no ping after 24 h · in graceNight 3no ping in 24 h + 1 h graceLate runGET /api/v0/wd/wd…200 ok
criticalwatchdog · nightly-backupNeeds you nowresolvedOutage · timeout · 40 minlogged
Watchdog down: nightly-backupConsole · Telegram · phone
Watchdog recovered: nightly-backupConsole · Telegram · phone
1Night 1: the backup pings its URL.
2Night 2: another ping, still up.
3Night 3: no ping. It goes late.
4Grace runs out: down, an alert.
5One notification reaches you.
6The late run pings: up, all-clear.
Cron watchdogs
Your job pings a URL on schedule. Miss one past its grace period and you hear about it.
sshd-bruteforce-web1SSH brute force on web1 · erroropenresolved
cron on web1Console
POST …/sshd-bruteforce-web1openedPOST …/sshd-bruteforce-web1counted, no notificationdednetsctl signals resolve sshd-bruteforce-web1
errorsignal · web1 · ×1Needs you nowerrorsignal · web1 · ×2Needs you nowerrorsignal · web1 · ×14Needs you nowresolvedsignal · web1 · ×14closed
SSH brute force on web1Console · Telegram · phone
Signal resolved: SSH brute force on web1Console · Telegram · phone
1A cron job on web1 spots SSH attacks.
2It opens a signal: one notification.
315 min later: ×2, no new message.
4×14 reports, still one notification.
5It clears: the script resolves it.
6One all-clear, then quiet.
Signals
Your scripts report what they find. One alert per problem, however many times it is reported.
Your network is ready
Connect the machines you already have.
Start with one private service. DedNets takes care of finding the path.