dev.site gives you a page at dev.site/@you. It holds links and services. A service is a TCP port on one of your machines, for example a database or a development server. You choose who can see and use each item.
An example
You run Postgres on port 5432 on your laptop. A teammate needs to query it. On your laptop, name the port and keep the daemon running:
devsite service host 5432 --name postgres
devsite daemon run
Share postgres with your teammate on the dashboard. They accept the share, get a ticket from your profile, and run:
devsite connect dst_***
# connected to postgres
# listening on 127.0.0.1:43127
Their psql now connects to 127.0.0.1:43127. The data goes from their machine to yours. Your laptop does not open a port to the internet.
Links work in the same way, without the daemon:
devsite link set --name docs --url https://docs.example.com --public
Install
Then sign in, create a machine ticket on the dashboard, and use it on this machine:
devsite login dmt_***
What dev.site sees
dev.site handles sign-in, profiles, shares, and permission for each connection. It does not carry your service data. It does not know your local port numbers.
host clidev.siteapproved user
prove + register bound endpoint
sync authorization snapshot
redeem one-use ticket + client key
client-bound session
request one-stream capability
signed capability + daemon id
end-to-end encrypted Iroh QUIC
Give an agent limited access
A sandboxed agent can ask for a service by name. You see the request and approve it. The agent then gets a short-lived grant for that one service. You can revoke it.