docs: document native macOS and Windows support - #900
Merged
Conversation
Keploy now runs natively on macOS (userspace interception, no eBPF, no privileges) and on Windows/x86-64 (the WinDivert driver), covering Go, Node, Python and Java apps. The docs still said "Keploy does not natively support macOS/Windows" and routed everyone to Lima, WSL or Docker. - installation/macos.md, installation/windows.md: add a native "Option 1" with record/replay steps, keeping Lima/WSL/Docker as alternatives. Note the macOS no-sudo behaviour, the launcher caveat (run the real executable, not `npm start`), and that Go HTTPS is handled without touching the keychain. - concepts/platform-requirements.md: mark macOS and Windows as natively supported in the "Without Docker" column, with the Windows/ARM and container routes still listed. - keploy-explained/dev-guide.md, server/installation_tabs.md: correct the "does not natively support macOS" statements. Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>
Native Windows interception used a kernel packet-filter driver, which could only load from an elevated terminal. Keploy now instruments the application it starts and intercepts its network calls in user space instead, so the driver — and the Administrator requirement with it — is gone. - installation/windows.md: drop the "open an Administrator terminal" step and the WinDivert explanation, and state the two limits that come with instrumenting the application rather than filtering packets: Keploy has to be the one that starts it, and UDP traffic is not recorded. Hostname resolution is covered, so a dependency that no longer exists is still answered from its Mock on a replay. - concepts/platform-requirements.md: macOS and Windows are both userspace now, and neither needs sudo or Administrator. The `wsl --install` steps keep their "as Administrator" note — that genuinely needs elevation and is unrelated. Blocked on keploy/keploy#4476, which removes the driver. Do not merge before it ships, or the page will describe behaviour users do not have yet. Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>
The prettier lane fails on this PR because installation/macos.md carries two consecutive blank lines. Prettier collapses them, and the check runs over every file the PR touches, so the whole lane goes red on whitespace. Content is untouched — this is the output of `prettier --write` on that one file, and every file this PR changes now passes under both prettier 2.8.8 (the version .github/workflows/prettify_code.yml asks for) and 3.9.6 (the version the action actually installs). Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>
prettify_code.yml passes prettier_version: 2.8.8 to creyD/prettier_action@v4.6, and the action ignores it — the run log reads "The following package was not found and will be installed: prettier@3.9.6". So the formatting contract CI enforced was not the one CONTRIBUTING and .prettierrc.json describe, and the two could drift apart silently: a file formatted to the documented version could fail the check, and a file the check accepts could be wrong by the documented version. Calling prettier directly removes the ambiguity — `npx prettier@2.8.8` runs 2.8.8 — and drops a third-party action from the path for a one-line command. 2.8.8 stays because it is what this repository is formatted with: across versioned_docs/version-4.0.0, 23 files diverge from 2.8.8 and 29 from 3.9.6. Moving to 3.x reflows markdown and is a deliberate migration, not something to inherit from an action's default. Signed-off-by: Shubham Jain <shubhamkjain@outlook.com>
slayerjain
force-pushed
the
feat/native-macos-windows-support
branch
from
August 23, 2026 07:58
c60a5c7 to
dcc4169
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
Keploy now runs natively on macOS and Windows — the docs still said it does not, and sent every macOS/Windows user to Lima, WSL, or Docker.
sudo, nothing installed system-wide), covering Go, Node, Python, Java including their HTTPS traffic.Most users run the community edition, which is the Keploy binary — so this is the default experience now, not an enterprise-only path.
Pages updated (all in the live
version-4.0.0)installation/macos.md— new Option 1: Run Keploy natively with record/replay steps; Lima/Docker demoted to alternatives. Notes: no password prompt, run the real executable (notnpm start— macOS drops the interception through a launcher), and Go HTTPS works without touching the keychain.installation/windows.md— new native Option 1 (Administrator + WinDivert), WSL/Docker as alternatives, x86‑64 note.concepts/platform-requirements.md— macOS and Windows marked natively supported in the "Without Docker" column; Windows/ARM and container routes still listed.keploy-explained/dev-guide.md,server/installation_tabs.md— corrected the "does not natively support macOS" lines.Notes for reviewers / timing
keploy-explained/mac-linux.md) as-is; it is now reachable as the "Lima" alternative rather than the only path.