Energy & renewables
Remote maintenance access to edge gateways and field computers at solar and wind sites, energy monitoring installations and EV charging locations. Reach existing web panels or maintenance services.
Explore energy access →
In development · not yet publicly available
FOR ENERGY & INDUSTRIAL IOT
Your field edge.
One direct link.
From energy sites to production lines, reach services on your edge devices over encrypted WebRTC connections. We’re building EdgeSocket with flexible cloud and on-premises options for different field requirements.
DTLS encryptedCloud + on-premisesTCP + UDP
FOLLOW YOUR CONNECTIONInteractive diagram
Direct data path
Service traffic travels between your two clients. Signaling carries no application payload.
Control & authorizationEncrypted service traffic
*When a direct path is available. Restrictive networks can use an authorized TURN relay. The diagram illustrates connection paths.
SAME TOOLS. A NEW WAY TO CONNECT.SSHPostgreSQLHTTP / APIsRDPDNS / UDP
BUILT TOWARD REAL FIELD NEEDS
From energy sites to production lines.
We’re developing remote access for industrial IoT gateways, field computers and distributed edge devices. The goal: reach the service you need, with access tied to the right person and device.
Manufacturing & industrial IoT
Access existing services on machine-data gateways and industrial PCs across production lines. A device-based access model for maintenance teams and authorized service partners.
Explore industrial edge access →Logistics & retail
Reach local applications and edge services across warehouses, distribution centers and stores. Support geographically distributed sites through authorized device access.
Buildings, utilities & agriculture
Access gateway interfaces and local edge applications in building automation, water management and agricultural monitoring. Keep using the tools and services already deployed in the field.
Target use cases for a product in development. Device and protocol compatibility will be assessed for your setup.
Tell us about your field setup →
01 / CONNECTION, REIMAGINED
Let your peers
Let your peers
do the talking.
The control plane checks access and introduces your devices. WebRTC carries the data. Your service stays yours.
Identify. Authorize.
Separate user and device tokens. Access is checked against the target device before the session starts.
Find a direct path.
Signaling exchanges SDP and ICE candidates. WebRTC evaluates the available paths between peers.
Connect your service.
Forward TCP streams and UDP datagrams through encrypted data channels. Use an authorized TURN relay when direct connectivity fails.
WHEN DO YOU NEED TURN?Illustration
Try direct. Relay if needed.
First, find each other.
Signaling introduces the authorized peers. STUN helps discover public addresses; ICE checks connection candidates.
DTLS encryption on both paths
Illustration, not a live connection. TURN requires an available relay and access permission.
P2P first. TURN when needed.
UNDER THE CONNECTION
WebRTC. Beyond video calls.
WebRTC can carry application data as well as audio and video. EdgeSocket uses its data channels to connect your existing TCP and UDP services.
01Your serviceSSH · SQL · HTTP · DNS
02Data channel / SCTPCarries streams and datagrams
03DTLSEncrypts data between peers
04ICE · STUN · TURNFinds a working network path
Your protocol stays familiar.
The local client accepts your TCP connection and forwards its bytes over a reliable, ordered data channel. The edge client opens a separate TCP connection to the service. UDP datagrams use an unordered channel without retransmissions.
Discovery first. Relay when needed.
STUN helps discover a peer’s public network address. ICE checks candidate paths. If direct connectivity fails, a configured TURN server relays the encrypted packets. STUN and signaling do not carry your service traffic.
Permission follows the device.
User and device tokens identify both ends. Signaling checks the target-device grant; TURN checks the same access policy plus the relay package. The control connection stays open for revocation checks. Port forwarding does not imply port-level ACLs.
BUILT FOR THE EDGE
Small footprint.
Small footprint.
Solid foundations.
Focus on your devices and services. We’re bringing connectivity, access control and relay when needed into one platform.
Peer-to-peer at the core.
ICE for path discovery. DTLS for encryption. Reliable channels for TCP; unordered, unreliable channels for UDP.
ICE · DTLS · SCTPRemote feels local.
Connect to SSH, databases, internal APIs, or RDP through a local port. Your existing service authentication stays in place.
Your tools. Your workflow.The right device. The right person.
Home owners reach their own devices. Enterprise users need explicit device grants. Signaling and TURN enforce the same policy.
Device-level authorization
02 / ACCESS IS A DECISION
Your devices.
Your devices.
Your rules.
A session name is not permission. Every connection belongs to an identity, an account, and a target device.
- Isolated home and enterprise accounts
- Explicit per-user device grants
- Revoke access to close active sessions
access.policyIllustration
01 / ADMINISTRATOR
Assign device access
The administrator grants Ege Meriç Erdoğan access to factory-edge within the organization.
02 / USER’S DEVICE LIST
EME
Ece Melis ErdoğanAccount owner
Authenticated
home-gatewayYour account · SSH / HTTP
home-storageYour account · TCP services
Connect to edge devices registered to your own account. Enterprise accounts provide per-user device permissions for team access.
03 / THE APP WE’RE BUILDING TOWARD
Choose your edge.
Choose your edge.
Reach your service.
The planned desktop app will bring device selection, service access and connection status into one place. See the intended flow below; the GUI is not available yet.
Open your existing SSH app through a local connection.
An EdgeSocket client will still run at both ends. The app will manage the tunnel; your service’s own authentication remains in place.
edgesocket.GUI concept · planned
01
CHOOSE AN AUTHORIZED DEVICEfactory-edgeExample device · explicit user grant
02
CHOOSE YOUR SERVICESSH
TCP · 22
03
OPEN A LOCAL CONNECTION
127.0.0.1:2222
Preview: choose a service, then follow the connection flow.
Flexible deployment. One connection experience.
Use the cloud option or deploy the complete system in your own environment to meet your organization’s needs. Our goal is the same straightforward app experience for reaching authorized edge devices in either setup.
01Cloud deployment option
02Full on-premises when needed
03A simple app for everyday access
Both deployment options are part of the product plan. EdgeSocket is still in development; general access is not open yet.
WHAT WE’RE BUILDING FOR YOU
Connect with less effort.
Connect with less effort.
Stay focused on your work.
The connection core is implemented. Next comes an accessible app and a managed service experience. Planned capabilities are not available yet; there is no committed launch date.
Reach your devices securely
- Direct WebRTC connections
- Encrypted TURN relay when needed
- Access to existing TCP/UDP services
- Home ownership and team device permissions
One app, a clear path
- Sign in with your account
- Find the devices you can access
- Choose a service and connect
- See connection status and helpful guidance
Cloud or on-premises
- Access through the cloud
- Full-system on-premises deployment when needed
- Organization and team access
- Relay packages suited to your needs
A FEW GOOD QUESTIONS
Let's make it clear.
Does my traffic always go peer-to-peer?
WebRTC evaluates available ICE paths. Application traffic is direct when that path works; when it does not, configured and authorized TURN allocations can relay it. A paid relay package is required by the built-in commercial TURN server.
Do I need a client on both sides?
Yes. The field device and your computer each need an EdgeSocket client. In the planned desktop app, you’ll choose an authorized device and service to connect. You can keep using your existing SSH, database or web app.
Can I limit access to individual TCP ports?
You can choose the service port you forward. Authorization currently applies to the whole device, not individual ports or services. Service-level policies require a separate future design; the service's own authentication remains important.
Will on-premises deployment be available?
Yes. We’re planning flexible cloud and on-premises deployment options. On-premises will let the complete system, including management and connectivity components, run in your own environment. Share your use case and requirements with us.
Is the platform available yet?
Not for general use yet. The connection core is implemented; we’re working toward the cloud platform and end-user app. Leave an early-access request or share your use case.
LET’S BUILD WHAT YOU NEED
Not quite ready. Ready to listen.
EdgeSocket is still in development. Tell us what you want to connect, leave a question, or request early access. We can contact you about your request at the email you provide.
- Tell us your use case
- Share the devices and services you need
- No account or payment required
This is a request, not an active account or a promise of an access date. Please do not include passwords, tokens, or other secrets.