GG-Socket vs gsocket.io:
The Complete 2026 Comparison

GG-Socket and gsocket.io attack the same problem from opposite directions: bridging two machines that can’t otherwise reach each other, using nothing but a shared secret. gsocket.io solves it as a hosted service; GG-Socket solves it as a piece of software you install on your own server. That choice — their hardware versus yours — is the whole story.

If you point any secret-key client at a GG-Socket relay it behaves the same way it would against gsocket.io’s. The difference is where the bytes travel, who sets the limits, and who can read the logs.

The Shared Idea

Both projects rest on one mechanism:

1. The first peer connects out to a relay and parks, identified by a secret string.
2. The second peer connects out to the same relay with the same string.
3. The relay notices the match and copies bytes between the two sockets until one closes.

Because both legs are outbound, neither machine needs a routable address or an open port. Carried over TLS on port 443, the traffic looks ordinary enough to cross most residential and corporate networks.

Where They Diverge

Privacy, Concretely

With the hosted service, every handshake — and therefore the secret that authenticates it — transits someone else’s infrastructure. That may be perfectly fine for casual use. It is not fine when the traffic is sensitive, regulated, or simply none of anyone’s business.

GG-Socket’s relay is a Go process on a box you control. It terminates TLS, reads the secret to decide who pairs with whom, and then blindly forwards encrypted application bytes. There is no upstream it phones home to. If you ever want to prove where the traffic went, the answer is short: your VPS, and nowhere else.

Limits and Uptime

Shared relays throttle to survive abuse from everyone at once, and a busy afternoon on the free tier is enough to feel it. GG-Socket hands you the dials instead: a per-IP limiter (twenty new connections a minute by default) and a capacity semaphore (ten thousand concurrent sessions) that you can raise or lower. If you outgrow them, you change two environment variables.

Availability stops being a question of a vendor’s status page and becomes a question of your own server. A single small VPS idling on a Go binary is a simple thing to keep up, and docker compose up -d is a simple thing to rerun.

The Setup Trade-off

gsocket.io asks for nothing — create an account and go. GG-Socket asks for a VPS, a domain, and the two minutes it takes to bring up the stack:

# Stand up the relay + notify proxy
docker compose up -d --build

# Both peers then dial the same secret
gs-client GGK-XXXXX-XXXXX-XXXXX-XXXXX -r r.ggsocket.com:443

That is the entire bargain: a little setup in exchange for owning the relay, the limits, the domain, and the logs.

What GG-Socket Adds

Because the relay is yours and the source is open, a few things come with it that a hosted model cannot offer:

• Live metrics — active and total connections, matched sessions, bytes relayed, and every rejection counter, all in Prometheus exposition format at /metrics.
• Credential recovery — a Basic-Auth-protected /recover page that hands back a forgotten session password when you supply the secret key.
• Quiet first-run alerts — the notify proxy acknowledges a check-in instantly and forwards it to Telegram in the background, so the callback looks like ordinary web traffic.
• A real capacity story — the semaphore and rate limiter exist to keep the relay available under load, not to herd free-tier users.

Reach for gsocket.io when

• You want zero infrastructure — no server, no domain, no YAML.
• The connection is one-off and you do not care where it transits.
• You are kicking the tires on secret-key tunnelling before committing.

Reach for GG-Socket when

• The traffic must stay on infrastructure you own.
• You need predictable limits and an honest uptime story.
• You want metrics, recovery, and notifications included rather than bolted on.
• You would rather read the relay’s source than trust a black box.

Moving Off the Hosted Relay

Switching is mostly a matter of repointing clients:

# 1. Bring up your own relay (one time)
git clone <repo> gg_socket && cd gg_socket
cp notify.env.example notify.env   # fill in secrets
docker compose up -d --build

# 2. Repoint each peer at r.ggsocket.com:443 with a fresh secret

New secrets are generated per deployment; nothing about the client experience changes once the relay address moves.

docker compose up -d --build