No-Logs Policy

Last Updated: July 9, 2026

This No-Logs Policy describes, in precise terms, what Foggy Froggy Networks ("Foggy Froggy Networks," "we," "us," or "our") does not record about your use of our VPN service, what minimal operational data exists on our systems and why, and how you can independently verify the protections we claim. This document is a binding commitment and forms part of the agreement described in our Terms of Service; it should be read together with our Privacy Policy, which covers account and billing data. Our slogan is "Stay in the fog!" — and the purpose of this Policy is to define exactly what that fog covers.

1. Our Philosophy

A VPN provider occupies a position of extraordinary trust: every packet a subscriber sends passes through infrastructure the provider controls. We believe the only honest way to hold that position is to be structurally incapable of betraying it. Foggy Froggy Networks therefore treats logging not as a policy question but as an engineering constraint. Our VPN nodes are built so that the sensitive records other companies promise not to disclose are, on our network, never written in the first place. A promise can be broken under pressure; an absence of data cannot. Data that does not exist cannot be subpoenaed, seized, stolen, leaked, sold, or misused by a rogue employee.

2. Precise Definition: What Is Never Logged

On the VPN servers that carry subscriber traffic, Foggy Froggy Networks does not record, in any form, at any time, in memory-persistent or disk-persistent storage:

• Browsing history: no record of websites visited, applications used, or services accessed;
• Traffic destination data: no destination IP addresses, hostnames, ports, or protocols of your connections;
• DNS queries: our resolvers, which provide DNS leak protection, answer queries and immediately discard them, with query logging disabled at the resolver software level;
• Traffic content: no packet payloads, deep packet inspection records, or metadata derived from the content of communications;
• Connection timestamps tied to identity: no record of when a specific account or originating IP address connected to or disconnected from a specific server;
• IP address mappings: no logs correlating your real IP address with a VPN-assigned IP address at any point in time;
• Session duration or per-session bandwidth records attributable to an identified session;
• IPv6 traffic records: with full IPv6 readiness and IPv6 leak protection, IPv6 flows receive exactly the same non-logging treatment as IPv4 flows.

There are no exceptions to this list for "diagnostic modes," "temporary debugging," or law-enforcement cooperation. If a category of data appears above, our infrastructure is configured not to produce it.

3. What Minimal Operational Data Exists, and Why

Running a reliable network requires some information, and we believe honesty requires listing it exhaustively rather than pretending it does not exist. The following is the complete set of operational data associated with your use of the VPN:

• Authentication state: when your device connects, a node verifies with our central systems that your subscription is active and that the device's hardware identifier occupies a valid device slot (1 HWID = 1 Device). This is a real-time yes/no check; the node does not retain a record of the check after the session ends.
• Aggregate bandwidth counters: running per-account totals of data transferred, used for capacity planning and abuse prevention. These are cumulative numbers without timestamps, destinations, or session boundaries, and they are reset on a rolling basis as described in our Privacy Policy.
• Concurrent slot occupancy: an ephemeral in-memory count of which device slots are currently in use, so plan limits (5 devices on SOLO, 20 on FAMILY, 50 on PRO, 250 on CORPORATE) can be enforced. This state disappears when a session ends.
• Server health telemetry: CPU load, memory pressure, disk health, and aggregate throughput per node, feeding our 24/7 infrastructure monitoring and supporting our 99.9%+ uptime target. This telemetry is measured at the machine level and contains no per-user or per-connection detail.

None of this data can be used to reconstruct what any subscriber did online, when they did it, or where their traffic went.

4. RAM-Oriented Operations and Our Hardware

Our nodes run on AMD EPYC servers with ECC RAM and NVMe SSD storage, and the architecture leans deliberately on the volatile side of that hardware. All session state — cryptographic key material, tunnel assignments, slot occupancy, and DNS resolution workspaces — lives exclusively in RAM and is destroyed when the session closes or the machine restarts. ECC RAM gives us the reliability to keep this state in volatile memory without corruption, and the high memory bandwidth of the EPYC platform lets us serve up to 1 Gbps per connection at 30 to 50 ms average latency without ever spilling session data to disk. The NVMe SSDs hold only the operating system, the VPN software, and configuration; system journals on traffic-carrying services are directed to volatile storage or disabled. A powered-down or seized node therefore contains no user activity data to recover.

5. Fewer Than 100 Users Per Node: A Privacy Feature

We cap every node at fewer than 100 concurrent users, and while this is usually described as a performance guarantee, it is also a privacy design choice with two sides that balance each other. On one hand, shared exit addressing means your traffic leaves each node blended with that of the other subscribers on it, providing crowding-based anonymity: an outside observer watching a node's exit IP cannot attribute a given flow to a given subscriber, and we hold no records that could resolve the ambiguity. On the other hand, keeping the population per node small ensures the machine never needs the heavyweight per-user accounting, queuing, and shaping subsystems that dense multi-tenant VPN hosts rely on — subsystems that typically require exactly the per-session records we refuse to create. Low density lets us run simple, stateless, log-free nodes at full performance.

6. Handling of Third-Party Requests

We may receive inquiries from law enforcement agencies, civil litigants, or copyright claimants. Our handling procedure is fixed: every demand is reviewed for legal validity, jurisdiction, and proper service, and we reject demands that fail any of these tests. Where a demand is valid and enforceable, we can produce only what exists — the account email address, subscription plan, payment transaction records held as described in our Privacy Policy, and aggregate bandwidth totals. We cannot produce browsing history, traffic destinations, DNS queries, connection timestamps, or IP address mappings, because our infrastructure does not generate them; this is a technical fact, not a negotiating position. We do not build, and will not accept requests to build, interception or logging capabilities targeting individual subscribers. Where we are not legally prohibited from doing so, we will notify an affected subscriber before disclosing their account data.

7. Jurisdiction

Foggy Froggy Networks is based in Cody, Wyoming, United States. The United States has no law imposing mandatory data-retention obligations on VPN providers, which means no statute compels us to log subscriber activity, and our no-logs architecture is fully lawful in our home jurisdiction. Our servers operate in 17 countries — the United States, Canada, the United Kingdom, Germany, the Netherlands, France, Switzerland, Sweden, Finland, Poland, Singapore, Japan, South Korea, Australia, India, Brazil, and Turkey — and every node runs the same log-free configuration regardless of location. If the legal environment of any hosting country were to change in a way that required activity logging, our response would be to withdraw infrastructure from that country rather than comply, and we would inform subscribers of the change in our server list.

8. Audits and Transparency

Claims of no logging deserve scrutiny, and we intend to earn trust through verification rather than assertion. Our approach has three parts. First, our node configurations are standardized and internally reviewed so that every server in every country is provably running the same log-free build. Second, we are committed to engaging reputable independent security firms to audit our no-logs architecture and to publishing the material findings of such audits as they are completed. Third, we maintain a transparency practice of publicly reporting, on a periodic basis, the number and general nature of legal demands we receive and our responses, to the fullest extent the law allows. Founded in 2026, we make these commitments at the start of our operating history so that our record can be measured against them from day one.

9. What This Policy Does Not Cover

For completeness: this Policy governs activity data on our VPN infrastructure. It does not alter the limited account and billing data practices described in our Privacy Policy — your registered email address, payment records held by payment processors, HWID bindings for device-limit enforcement, and aggregate bandwidth counters. It also cannot protect you from data collection that happens outside our tunnel: websites you log into still know who you are, your device's operating system and applications may keep their own histories, and your internet service provider can see that you are connected to a VPN (though not what you do through it). A VPN is a powerful privacy layer, not a substitute for good operational security.

10. Verify It Yourself: Leak Testing

We encourage every subscriber to independently verify the protections we advertise rather than take our word for them. We recommend the following routine checks:

• IP address check: while connected, use any public IP-lookup service and confirm that the address shown belongs to the Foggy Froggy Networks server you selected, not to your internet service provider.
• DNS leak test: run a DNS leak test from your browser while connected. All resolvers reported should be Foggy Froggy Networks resolvers; if you ever see your ISP's resolvers, disconnect and contact support immediately.
• IPv6 leak test: because the Service is IPv6 ready with IPv6 leak protection, an IPv6 test while connected should show either a Foggy Froggy Networks IPv6 address or no IPv6 connectivity — never your home IPv6 prefix.
• Kill-switch check: if you use our client's kill switch, briefly disable your network adapter and re-enable it, confirming that no traffic escapes outside the tunnel during reconnection.
• WebRTC check: verify in your browser that WebRTC does not expose your real IP address while the tunnel is active.

If any of these tests ever produces an unexpected result, we treat it as a serious defect. Please report it to our support team so we can investigate and correct it.

11. Changes to This Policy

We may update this No-Logs Policy to add detail, describe new verification tools, or reflect audit outcomes. What we will not do is weaken it: no revision of this Policy will introduce the logging of browsing history, traffic destinations, DNS queries, traffic content, connection timestamps tied to identity, or IP address mappings. Material updates will be announced to subscribers by email or in-service notice, and the "Last Updated" date above will always reflect the current version.

12. Contact

Questions about this No-Logs Policy, reports of unexpected leak-test results, or requests for more technical detail about our architecture may be directed to Foggy Froggy Networks using the contact details below.