FlowDriver and the case for a cloud folder as a network queue

A Drive folder used as a queue, not a relay

The mechanism is the interesting part, and it is short. FlowDriver works by treating a cloud storage folder as a data queue.

The client side captures local SOCKS5 requests and bundles them into a compact binary protocol. Those binary packets are uploaded to a specific Google Drive folder. The server side continuously polls the Drive folder, and when it finds a request from a client, it downloads it, opens a real TCP connection to the destination, and sends back the result as a response file.

That is the whole architecture. There is no custom protocol on a custom port, no relay server that needs a stable address, and no long-lived connection between the client and the server. The traffic that crosses a filtering network is a sequence of ordinary API calls to a storage service, which is why the project describes it as leveraging legitimate API traffic.

The tradeoff is inherent to the design. A file queue has no ordering guarantee you can rely on, no delivery confirmation beyond what the polling loop observes, and a latency floor set by how often each side polls. What it gains is that the endpoints are ordinary HTTPS requests to a service that is already allowed to be reachable, which is the entire point when the network in question blocks arbitrary destinations.

The project is MIT licensed, written in Go, and describes itself as a covert transport system designed to tunnel network traffic through common cloud storage platforms like Google Drive.

The build is two commands and the config is two JSON files

The project has a small surface. It is a Go module, github.com/NullLatency/flow-driver, requiring Go 1.25.6, and it has exactly one external dependency, github.com/things-go/go-socks5 at version 0.1.1, which is the SOCKS5 server side.

Building produces two binaries:

go build -o bin/client ./cmd/client
go build -o bin/server ./cmd/server

The client configuration carries the transport details that make the traffic look like what it claims to be:

{
  "listen_addr": "127.0.0.1:1080",
  "storage_type": "google",
  "google_folder_id": "YOUR_FOLDER_ID",
  "refresh_rate_ms": 100,
  "flush_rate_ms": 300,
  "transport": {
    "TargetIP": "216.239.38.120:443",
    "SNI": "google.com",
    "HostHeader": "www.googleapis.com"
  }
}

The transport block is the part that determines what the network sees. The TargetIP is a Google address on port 443, the SNI is the server name sent in the TLS handshake, and the HostHeader is the value sent in the HTTP request. All three are set to values consistent with talking to the Drive API, so the connection does not present as a tunnel to a random endpoint.

The server configuration is the same minus the transport block, because the server is the one initiating the connections to Google:

{
  "storage_type": "google",
  "google_folder_id": "YOUR_FOLDER_ID",
  "refresh_rate_ms": 100,
  "flush_rate_ms": 300
}

Both sides need the same folder id, since that folder is the shared queue. The repository ships client_config.json.example and server_config.json.example at the top level, so the examples are the starting point.

The API quota, not the bandwidth, is the real limit

The performance section is short and it is the most important thing in the documentation.

Google Drive has strict API rate limits, described as quotas. The guide's guidance is that using very low values, for example refresh_rate_ms of 100, will consume your API quota very quickly. To avoid connections being limited or blocked, it is recommended to keep these values above 100ms at all times. For heavy usage or multiple concurrent users, you should set them to 200ms or higher.

Read that again in terms of how the tool works, because it reframes the whole system. The refresh rate is how often the server polls the folder and how often the client checks for responses. A faster poll means a lower round trip time and a higher request count. Since every poll is a Drive API call, the latency of the tunnel is bought directly with quota.

So the practical ceiling on this design is not bandwidth, it is request budget. A user who leaves the example value of 100 in place and runs the client continuously will find the account throttled or blocked, and the guide says so plainly. A user who sets 200 or 300 milliseconds trades latency for a quota that lasts.

This is also why the two rates exist separately. The refresh rate governs how often each side looks for new work, and the flush rate governs how often outbound packets are batched before being written to the folder. They are a latency knob and an efficiency knob, and the example values of 100 and 300 reflect a default that is fast but hungry.

OAuth2 credentials, and a token that expires in seven days by default

Both binaries need a Google Drive API credentials file, credentials.json, produced through OAuth2. The guide points at the Google Drive API Go Quickstart and then spells out the console steps: enable the API in the Google Cloud Console by creating a project, configure the OAuth consent screen with the app name and a user support email under Branding, create credentials as an OAuth client ID with the Desktop App application type, download the client secret file and rename it to credentials.json.

The fifth step is the one that saves a repeat visit. If your app status is Testing, your token will expire every 7 days, and the fix is to go to the OAuth consent screen and click Publish App to make the authorization permanent for your account.

The initial authentication is a three-legged OAuth2 flow that you only do once on your local machine. You run the client, a link appears in the terminal which you copy and open in a browser, log in to your Google account and grant permissions, and you are redirected to an address starting with http://localhost. The guide notes it is okay if that page does not load, because the step that matters is that you copy the entire URL from the browser's address bar and paste it back into your terminal. The program then creates a .token file next to your credentials.json, and authorization is complete.

There is also a convenience in the folder setup. If you leave google_folder_id empty, the tool automatically creates a folder named Flow-Data and saves its id to your config, so the shared queue does not have to be created by hand.

Running the two halves and what the dependency list implies

Once the credentials and configs are in place, the two sides start with the same flags:

./bin/server -c server_config.json -gc credentials.json

and

./bin/client -c client_config.json -gc credentials.json

The -c flag points at the config file and -gc at the Google credentials file, and the server runs where it can reach the destinations while the client runs where SOCKS5 traffic is generated. The client listens on 127.0.0.1:1080 in the example config, which is the conventional local SOCKS5 port, so pointing a browser or an application at it needs no unusual configuration.

The repository layout is minimal and matches the scope. At the top level there are the two example config files, go.mod, go.sum, the cmd/ directory holding the two commands, internal/ for the implementation, scripts/, a project description and a LICENSE.

The go.mod is worth one further look because it is short. A single external dependency, the SOCKS5 server library, means the storage layer, the packet protocol and the transport handling are all in this repository. For a tool that handles arbitrary destination addresses on behalf of a remote client, that is a small amount of code to review, and it is also a small amount of code that has to be trusted by whoever runs the server, since the server is the component that opens connections to arbitrary destinations on behalf of whoever can write into the shared folder.

The primary language is Go, and the module requires Go 1.25 or higher according to the prerequisites.

The disclaimer, the licence and where this stops being the right tool

The project states its own limits in a disclaimer at the top of the documentation. It is intended for personal usage and research purposes only, should not be used for illegal purposes, and should not be used in a production environment. The authors state they are not responsible for any misuse of the tool.

That last part, the production environment exclusion, is the most important line for an evaluator, and the reasons are structural rather than legalistic. The transport is a polling loop over a file queue, so a dropped response file or a throttled API call turns into a stalled connection rather than a retransmitted packet. The binary protocol is described as compact rather than as reliable, and the documentation does not describe retry semantics, delivery guarantees or flow control.

There is also a resource question that is easy to miss. Every user needs a Google account, a Google Cloud project and an OAuth client, and in a shared folder the server polls continuously whether or not anyone is using the tunnel. A team deploying this centrally would be spending one account's quota on behalf of many people, which is precisely the case the guide warns about when it recommends 200 milliseconds or higher for heavy usage or multiple concurrent users.

The release history shows active work. The tags are v0.0.3 from 2026-04-23, v0.0.4 from 2026-04-24 and v0.0.5 from 2026-05-11, and the last push to the repository was on 2026-05-17. The version numbers below 1.0 and the tight release spacing suggest a project still finding its shape, and the topics attached to the repository, covering covert transport, DPI, SNI, tunnelling and Google Drive API, describe the niche it occupies rather than a general purpose VPN.

Editorial conclusion

FlowDriver suits a researcher or an individual in a restrictive network who needs a working SOCKS5 path and already has a Google account and a Google Cloud project, since the transport is a file queue rather than a custom protocol and the whole setup is two Go binaries and two JSON files. It does not suit heavy or multi-user use, because the mechanism is bounded by the Drive API rate limit rather than by bandwidth, and it does not suit anyone who needs low latency or guaranteed delivery. Before deploying it, read the quota section and set refresh_rate_ms and flush_rate_ms to 200 or higher, publish the OAuth app so your token does not expire every seven days, and note that the last push was on 2026-05-17 with version v0.0.5 published on 2026-05-11.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NullLatency/FlowDriver on GitHub
4. README
5. Releases