S4M — private network infrastructure: VPN & proxies

01Project overview

S4M is private network infrastructure assembled into a single product: a WireGuard and OpenVPN VPN for the whole device, authenticated SOCKS5/HTTP proxies for scripts and automation, dedicated static IPs, and private servers of your own. All of it lives in one account, with one billing and one point of control. The positioning fits into two short lines from the homepage: "Hide your real IP. Own your privacy."

It's worth fixing the frame right away. S4M is a privacy tool for legitimate work: shielding automation and origin servers from address disclosure, crawling your own monitoring targets without exposing a production IP, and browsing privately from any device. That is exactly how the product describes itself: your automation and your server stay invisible — third parties see the exit node, and only the exit node. No promises to "bypass" or "trick" anyone: this is infrastructure that settles the question of traffic origin as matter-of-factly as a CDN settles the question of delivery.

We designed and built S4M end to end — the network architecture with its two planes (VPN and proxy), usage accounting, the dashboard and billing, the public catalog of free proxies with continuous checking, the documentation, the guides, and the trilingual site (EN/UK/RU). Below we walk through what the product is made of, how no-logs and commercial metering are reconciled, and why the formula "two products — one secure exit" became the backbone of the whole architecture.

And one more layer of context. S4M is a product of the studio's own ecosystem, and it didn't stay a showcase: today the entire server-side outbound traffic of our other products — from HTTP calls to external APIs to mail submission — flows through its authenticated SOCKS5 exit. The infrastructure this case study is about runs in our own production every day, and that is the best test we could possibly put it through.

02Context and the problem

Hiding an IP is easy "technically" — the hard part is turning it into infrastructure: reliable, manageable, and honest with the user. As we broke the task down, a familiar list of pains emerged — one that anybody working seriously with networks will recognise:

• The origin server gives itself away. Every outbound HTTP call and every email sent shows the third party the server's real address — and from the address one can find the hosting, the neighbouring services, and the attack surface.
• A zoo of tools. VPNs for people and proxies for machines traditionally live in separate products: two accounts, two billings, two support desks — and no shared usage control anywhere.
• Public proxies are unreliable. Free lists die fast, have no authentication, and their anonymity is unknown. Fine for a quick test, unusable for real work.
• Limits after the fact. Usage is normally computed from logs at the end of the period: an overrun is noticed once it has already happened. For a network product that is too late — and too expensive.
• Privacy in words only. "We keep no logs" in a privacy policy is not the same thing as an architecture in which activity logs physically never come into existence.

The brief was this: build a single network infrastructure where VPN and proxies are two planes of one product, where the absence of logs is a property of the construction rather than a paragraph of legal text, and where limits are enforced in real time on the node itself. And the product had to stay simple on the outside: an account in seconds, a config or credentials in a couple of clicks, and the result verifiable with a single command.

A separate layer is trust. A privacy product sells precisely that, and trust can only be earned with honesty: saying plainly that free public proxies are a test, not production; that anonymous sign-up is an option, not a billing trick; that no-logs is about what the server doesn't record, not about what it "won't show". This honesty was baked into the copy, the interfaces, and the FAQ from day one — as a product requirement, not a tone of voice.

03Project goals

From the brief grew concrete goals that we held onto at every stage — from the node layout to the copy on the landing page:

• One account — two products. VPN and proxies share the account, the billing, and the control panel; the user doesn't assemble a kit out of separate services.
• No-logs by design. RAM-first nodes and WireGuard keys on the user's side: the absence of activity logs is a property of the architecture, not a policy clause.
• Control on the wire. Fine-grained limits per plan / per IP / per account enforced in real time on the node itself, not after the fact from logs.
• API-first. Everything you can do in the dashboard you can do programmatically: a REST API with tokens, available from the base plan.
• Predictable pricing. A flat monthly rate for the VPN, metering for proxy traffic, a dedicated IP as an add-on — no hidden markups.
• Anonymity as an option. Sign-up without personal data, payment by card or crypto, cancel anytime.

As in our other products, the goals were framed as constraints — and each one cut off architectural options while still on paper. No-logs ruled out the classic billing pipelines built on log parsing: if there are no logs, accounting has to be streaming and live on the node. Real-time control forbade pushing limits into a "nightly recalculation". And API-first dictated that the dashboard is simply a client of the same API users get: there physically cannot be a capability reachable from the panel but unreachable programmatically.

04What we built

S4M composes a private network out of four product blocks that cover the whole spectrum — from "hide a laptop" to "hide a fleet of servers":

On top of these blocks sit a dashboard for managing configs, credentials, and limits; billing with card or crypto payment; a REST API with tokens; a library of guides and comparisons; and a trilingual site. Together it is one product with one data model — not four services under a shared signboard.

The key property is cohesion. One account produces both the VPN config and the proxy credentials; a dedicated IP attaches to either plane; usage accounting is one and the same no matter what form the traffic leaves in. The user thinks in terms of "hide the device" or "hide the script" — not in terms of "which of my five services is responsible for this".

05Architecture: two products, one exit

Inside S4M, the "two products" are two data planes over a shared core:

• The VPN plane — WireGuard and OpenVPN: encrypts the entire device. The user downloads a ready config and connects with one tap on any platform.
• The proxy plane — authenticated SOCKS5 and HTTP endpoints: routes a single application or script through the exit. Ideal for automation where a machine-wide VPN would be overkill.
• The shared core — accounts, plans, limits, usage accounting, and credential issuance: one data model both planes obey.

The second separation is control versus data. The control plane (dashboard, API, billing) decides who may do what: it creates access, assigns limits, counts money. The data plane (the exit nodes) executes: it terminates WireGuard/OpenVPN sessions, authenticates proxy connections, and enforces limits right on the wire. The nodes are built RAM-first: working state lives in memory rather than in durable logs — the foundation of the no-logs design covered in detail below.

And the third idea, promoted into the section title: one exit. Whatever the user relies on — a VPN tunnel for a laptop or SOCKS5 for a crawler — from the outside the same class of entity is visible: an S4M exit node. The third party sees the exit address and never the source address. One exit model means one security model, one accounting model, and one place where the rules are applied.

Finally, the architecture was designed from the start for the product line to grow. A dedicated personal IP is not a separate product but an attribute that binds to either plane: the same VPN or the same proxies, but with a stable address that belongs to you alone. A private server is the logical continuation: a personal data-plane node under the same management model, with no shared exit and no neighbours. Neither step required breaking the core — they fit into it by construction.

06How it works: three steps

The whole journey from "my IP is visible" to "my IP is hidden" the product phrases as "private in three steps" — and this isn't marketing shorthand but the actual onboarding path:

• 1. Create an account. Sign up in seconds — with an email or fully anonymously, with no personal data.
• 2. Pick VPN or proxy. Download a WireGuard/OpenVPN config for your device — or grab SOCKS5/HTTP proxy credentials for your script.
• 3. Connect. Traffic exits through an S4M node: third parties see the exit node — and never your real IP.

We specifically insisted that the result be verifiable with one command. Point any tool at an S4M proxy and the destination sees only the exit: curl --socks5 USER:PASS@node:1080 https://api.ipify.org returns the exit node's address, not your server's. It works with curl, Python, Scrapy, and any browser; the check against api.ipify.org takes seconds. That terminal block sits right on the product's homepage: the best argument for infrastructure is to show it working, not to describe it.

We treated "time to privacy" as a product metric from the start. If between sign-up and a hidden IP there lies a support thread, manual configuration, or a study of manuals — the product has lost, however strong the core. So configs are generated ready-made per platform, proxy credentials come in "paste into the command" form, and the onboarding path fits into minutes — from an empty sign-up form to a verified foreign address in the ipify response.

07Key capabilities

Let's look at what makes S4M not "yet another VPN" but production-grade network infrastructure.

VPN on WireGuard and OpenVPN

Two protocols cover the full range of devices and networks: modern, audited WireGuard as the primary and OpenVPN as the compatible fallback. The config is issued in one tap per platform, and pricing is a flat monthly rate with no surprises. Included are a kill-switch, split tunneling, and a DNS filter for ads, trackers, and malware: the VPN closes off not just the address but the background noise of tracking too.

Authenticated SOCKS5 and HTTP proxies

Datacenter proxies with username-and-password authentication: the credentials are yours alone, so no stray traffic rides your endpoint. Proxy traffic is metered — you pay for what you actually use. It's a working tool for crawling your own monitoring targets, for automation, and for any server-side job where the origin of a request must not point at the production machine.

Dedicated personal IPs

A static address that belongs only to you: ordered as an add-on, bound to the VPN or to the proxy, and — if you choose — kept unlinked from your identity. A stable exit matters wherever the address ends up on allowlists, or wherever IP reputation should depend on you alone.

Private servers

The top tier of isolation: your own server with your own IP in a region of your choice, with WireGuard/OpenVPN on board and the same no-logs discipline. No shared exit and no neighbours — the entire node works for a single customer.

Account, payment, cancellation

Sign-up by email or anonymously, payment by card or crypto via a billing partner, cancel anytime. Privacy starts with the product not demanding more data from the user than it needs to operate.

Usage management

Fine-grained limits per plan, per IP, and per account, enforced on the wire in real time. It's both infrastructure self-defence and a plan constructor — covered in detail in section 09.

08No-logs and privacy as engineering

S4M's core principle is to know no more than necessary. The exit nodes are built RAM-first: working state — sessions, connections, counters — lives in memory and never settles into durable logs. Browsing history isn't recorded at all: not because "we promised", but because the node's construction has no destination for it.

The second pillar is keys on the user's side. WireGuard keys are controlled by the account owner; proxy credentials belong to them alone. The infrastructure authenticates and routes, but makes no claim on the client's identity. The same goes for anonymous sign-up and crypto payment: the "account ↔ identity" link exists exactly as much as the user chose to create it.

This design shifts the threat model the right way. A node's value to any attacker or curious party is defined by what it stores — and a RAM-first node stores the operational minimum. We deliberately designed the system from the question "what would be left on disk on the worst day?" and drove towards the answer "nothing worth talking about". The same discipline binds the product itself: no "temporary" debug logs with user addresses can appear unnoticed, because the base construction contradicts them.

09Usage control on the wire

The most interesting engineering fork of the project was reconciling two requirements that at first glance exclude each other: no-logs and commercial metering. Classic metering is built on log parsing: collect the journals, tally them, issue the bill, notice the abuse. But we have no journals — so accounting has to live somewhere else.

S4M's answer: count on the wire. The node keeps streaming counters at the very moment it serves a connection — bytes and session counts, aggregated per account, plan, and IP. It counts volume, not content; counters, not events; aggregates, not browsing history. That is enough for both billing and limits — and it produces not a single record of the form "who went where".

Limits are enforced in the same place at the same moment: per plan, per IP, per account — in real time. The difference from the after-the-fact model is fundamental. End-of-month billing notices an overrun when the traffic has already left and the money is already lost; a limit on the wire is part of the service protocol itself: a connection either fits the rules or is not served. The infrastructure defends itself at the moment of the event, not with a letter after the fact.

For the administrator, the same mechanics become a plan constructor: a plan is a set of limits, not a line in a price list. A rule change propagates to the nodes and takes effect on live connections — with no credential reissue and no "effective from the next cycle".

10The free proxy list as a product

A product within the product is the live catalog of public proxies: hundreds of working SOCKS5/HTTP/HTTPS addresses (around eight hundred; the number fluctuates constantly) across 79 countries, with filters by country, protocol, and anonymity level. Unlike static "lists from the internet", the S4M catalog is checked continuously: dead addresses drop out, live ones are re-confirmed.

Behind the storefront runs our own pipeline: a crawler gathers candidates from open sources, and a checker re-verifies every address in rotation — whether it's alive, which protocol it answers on, what anonymity it provides, and which country it exits from. The result is not "today's list" but a live cross-section of the public proxy space, where every entry carries a fresh check mark. That continuity is the product: a list of addresses by itself is worth nothing; the value is that it is always current.

In the product's economics the catalog plays the role of an honest funnel. It is useful in its own right and brings in an audience that already needs network tools — and from there the product doesn't push, it explains. Right in the interface and the FAQ it says: public proxies are third-party servers from open sources; they're great for a quick test but not for sensitive traffic — use at your own risk. Next to it, a sober comparison: uptime, speed, authentication, guaranteed anonymity, a dedicated IP, usage control, and support exist only on the paid side. The user reaches the conclusion on their own, without ever being pushed.

11Dedicated IPs and private servers

A dedicated personal IP in S4M is a full lifecycle, not a line in a plan. The address is ordered from the dashboard, issued as static and personal — you alone use it — and bound to either plane: to the VPN, so the device always exits from one address, or to the proxy, so automation has a stable exit point. On request, the address is provisioned with no link to the owner's identity — privacy extends to the very fact of owning the resource.

Why this matters is clear to anyone who has worked with allowlists: a dynamic exit is good for privacy but bad for systems that expect you from a known address. A personal static IP solves both problems at once — the traffic's origin stays hidden behind the exit, while the exit itself is constant, and its reputation depends only on your own traffic rather than on the behaviour of pool neighbours.

The top tier of the line is the private server: your own dedicated node with its own IP in an OVH region of your choice, with WireGuard/OpenVPN on board and the same no-logs discipline. No shared exit and no neighbours: all the bandwidth, all the reputation, and the whole node belong to one customer. Architecturally it is the same data plane as the shared nodes — just deployed personally, so the panel, the limits, and the accounting work with it without a single caveat.

12Developer experience and the API

S4M was built as an API-first product: everything visible in the dashboard is available programmatically. The REST API with tokens is open from the base plan — creating and reading resources, configs, credentials, usage. Higher plans add webhooks and raised API limits, and for those building their own service on top of S4M — white-label and reseller sub-accounts. Provisioning access is an API call, not a support ticket.

We measured developer experience with a simple test: how many lines separate the credentials from working code. The answer is one — that same curl command with the --socks5 flag. The proxies work with curl, Python, Scrapy, and any browser with no special SDKs — these are standard protocols, not a proprietary wrapper. Verifying the exit is instant, against api.ipify.org. Around this sits a library of guides: how to hide a server's IP, VPN versus proxy, what a SOCKS5 proxy is, datacenter versus residential — the documentation works both as education and as an organic entry into the product.

The most telling integration is our own. The Ostohlo ecosystem routes all server-side outbound traffic of its products through S4M's authenticated SOCKS5 exit: every HTTP call to an external API and every mail submission leaves through an exit node, and the origin servers' IPs never touch third-party hosts at all. Here S4M is not "extra protection" but the standard egress layer production lives through.

That integration gave the product what no test bench can: the demands of real production. Exit stability, predictable credentials, limit behaviour under continuous load — all of it was proven not with synthetics but with the live traffic of services that must not go down. Every rough edge of the API hit us first — and was fixed before any outside user could have seen it.

13Technology stack and infrastructure

S4M runs in a dedicated environment with a clean separation: the panel and billing in one contour, the exit nodes in another. Management knows nothing about traffic contents; the nodes know nothing about payment data.

• Backend — PHP 8.3: the dashboard, billing, the REST API, the free proxy catalog and its crawler-checker.
• Network layer — the VPN plane (WireGuard/OpenVPN) and the proxy plane (SOCKS5/HTTP) on RAM-first exit nodes; coverage — 79 countries, stated uptime — 99.9%.
• Billing — payment by card or crypto via a billing partner; a flat rate for the VPN, metering for proxy traffic, add-ons for dedicated IPs and private servers.
• Perimeter — Cloudflare (DNS, TLS, protection) in front of the product's public surfaces.

The choice of PHP 8.3 for the control contour is pragmatic: a mature, fast platform where the dashboard, the API, billing, and the catalog live in one predictable environment. The network layer is deliberately separate and speaks standard protocols — WireGuard, OpenVPN, SOCKS5, HTTP: the user doesn't need our client; any tool they already use will do. The separation pays off operationally too: the panel can be updated without touching the nodes, and the nodes can be scaled and replaced without the panel noticing.

14Design and UX

A privacy product sells trust — and with a technical audience, trust is bought not with promises but with verifiability. So the main device of S4M's interface is "show, don't tell": right on the homepage lives a terminal block with the curl command and the ipify response, demonstrating the address swap in a single line. Next to it — live counters: the number of working free proxies in the catalog, the countries covered. These are figures from the product, not marketing constants, and a technical audience feels the difference instantly.

The same principle of honesty shapes the site's structure. The "free proxies versus S4M" table doesn't hide the free option's strengths; it calmly lays out where they end: uptime, speed, authentication, anonymity, control. The FAQ answers directly, including the uncomfortable parts: yes, public proxies are at your own risk; no, we don't record your activity; yes, you can stay anonymous. The guides and comparisons turn the site into a reference people come back to — and one that brings in a new audience.

The product is trilingual — EN/UK/RU, and this is not "a translated landing page" but a full localisation: the interface, the guides, the FAQ. For an infrastructure service, language is part of the UX: the user is making decisions about privacy, and they should make them in the language they think in.

15How we worked

The project ran in sequential stages with a working result at every step:

• Research. We mapped the scenarios — protecting origin servers, automation, private browsing — the threat model, and the way the market splits VPNs and proxies into separate products.
• Architecture. We designed the two planes over a shared core, the on-the-wire limit model, the no-logs node construction, and the API format.
• Core development. We built the VPN and proxy planes, streaming accounting, the dashboard, billing with card and crypto, and the issuance of configs and credentials.
• The proxy catalog. We built the crawler and the continuous checker of public proxies, the filters, and the catalog's live counters.
• Integration and run-in. We moved our own ecosystem's server-side egress onto S4M's SOCKS5 exit and ran the infrastructure under live production traffic.
• Launch. We produced the landing page, the guides and comparisons, the FAQ, and full localisation into three languages.

The order is deliberate: first the contract was fixed — config and credential formats, the limit model, the API scheme — and only then was the implementation built around it. A stable contract let us develop the core and the catalog in parallel, while our own ecosystem played the part of the first and most demanding customer: by the time of the public launch, real traffic was already flowing through S4M, and whole classes of problems had been found and closed from the inside.

16The result

What emerged is not "yet another VPN service" but network infrastructure in which the VPN, the proxies, dedicated IPs, and private servers are facets of one product with one model of accounting and privacy.

• One account covers the VPN, proxies, dedicated IPs, and private servers — with no zoo of services and no duplicate billing.
• Privacy in minutes: sign-up → config or credentials → the exit verified with one command against api.ipify.org.
• Per-plan / per-IP / per-account limits run on the wire in real time — and require not a single activity log.
• The free catalog of hundreds of live proxies brings in an audience and converts it honestly into paid plans.
• The product runs in our own production: the ecosystem's entire server-side outbound traffic flows through the S4M exit.

The main result is the shift of model. Before, "hide the IP" meant assembling a kit: a VPN here, proxies there, a static address from a third vendor, and shared control nowhere. Now it is one infrastructure with one point of control that serves a laptop and a fleet of servers alike — and that we ourselves use every day.

17Takeaways

S4M's central engineering story is the reconciliation of what looks irreconcilable: no-logs privacy and commercial metering. The solution — count bytes, not behaviour; on the node, not in a journal; as aggregates, not events — looks obvious in hindsight, but it is what shaped the entire architecture: RAM-first nodes, streaming counters, limits on the wire. Privacy here is not a feature and not a promise, but the shape of the construction.

The second takeaway is about trust. In a category where the product is bought for privacy, honesty turned out to be the strongest product strategy: a verifiable demonstration instead of slogans, live counters instead of round numbers, direct answers about the boundaries of the free tier. And the third is the power of "our own skin in the game": the best test of privacy infrastructure is to put your own production on it — which we did, routing the ecosystem's entire outbound traffic through S4M.

For us this was a project at the intersection of network engineering, product thinking, and that particular discipline where what matters is not what a server does but what it fundamentally does not do. If you need network infrastructure, an API-first service, or a product where privacy must be architecture rather than a policy paragraph — we know how to carry that through to launch.