Here are the questions we hear most often before adoption. If yours isn't here, feel free to contact us.
Yes. The Agent simply opens an outbound tunnel from your local machine or internal network, so there is no need to open inbound ports on your router or firewall. All your network needs to allow is outbound traffic on port 443.
You are right that, when the conditions line up, IPv6 lets you reach a device directly. If your server or Raspberry Pi has a global IPv6 address, the router and OS firewalls allow the target port, and the client side is also on IPv6, traffic goes "outside → IPv6 → your device" without any NAT in the way. Looking at NAT traversal alone, a tunnel is technically unnecessary.
However, all four of the following steps must hold for that to work:
A recent home fiber line often passes steps 1–3, but step 4 is where a great many networks stop. In corporate and factory LANs it is normal for the boundary firewall to reject new inbound connections even when the device holds a global IPv6 address, and guest Wi-Fi or LTE / 5G routers are even less promising. On the IPv4 side, many consumer contracts now use shared-address schemes (such as MAP-E) with restricted ports and cannot be used for publishing at all. In short, IPv6 has greatly reduced the "NAT wall," but the "firewall wall" does not go away with IPv6.
The WireCanal Agent works using nothing but outbound traffic on port 443, which is normally allowed everywhere. Devices that may end up on a factory Wi-Fi, an office VLAN, a guest line, or a mobile connection — "you never know which network it will be placed on" — can all be published with the same procedure regardless of the environment. That is the key reason a tunnel-based design exists.
The other difference is that with direct IPv6 exposure you have to build everything around the publication yourself. With WireCanal you get automatic HTTPS certificates, a memorable fixed hostname, reachability for visitors who only have IPv4, eight kinds of access protection (BASIC / Bearer / IP / country and more), scheduling and path-based scoping, and access logs — all from the dashboard. Once you enable IPv6 and open port 22 or a web port, the Internet can reach that port directly, which changes your security design substantially. WireCanal is built to never connect to anything other than the configured destination, and takes the burden of managing the exposed endpoint off your hands.
In one sentence: "With IPv6 a tunnel can be technically unnecessary — but environment-independent reachability and the features that make publishing safe and easy do not become unnecessary." That is what WireCanal is for.
Yes. The Agent is a single runtime-free binary (under 10 MB, roughly 10 MB resident memory) and, in addition to x86_64 Linux, we provide builds for 64-bit ARM (arm64) and 32-bit ARM (armv6 / armv7). From Raspberry Pi 5 / 4 / 3 / Zero 2 W, through 32-bit boards such as the Raspberry Pi Zero and Pi 2, down to Cortex-A7 boards with a few dozen MB of RAM like the Luckfox Pico, installation is the same one-liner (curl … | sh) as on a PC.
Because it runs on outbound traffic only, the procedure is identical whether the board ends up on a factory Wi-Fi, an office VLAN, or a mobile connection, and you can safely reach its web UI, API, or SSH (TCP canal, Pro and above) from outside. The list of supported chips and devices, plus articles on Raspberry Pi 5 and Luckfox Pico M, are collected on the IoT devices page.
The Agent is a static single binary for Windows and Linux — no runtime required, just place one file. Installation is a one-liner (irm … | iex on Windows, curl … | sh on Linux). See the per-OS setup guide for details.
Yes. All configuration and management — creating canals, setting access protection, checking access logs — is done in a web application (the dashboard) that runs in your browser. On the local machine you want to publish, you just place and run a single dedicated binary (the Agent) built for your OS (setup guide).
Yes. The dashboard is a web application, so you can operate it directly from your smartphone's browser. Pausing and resuming canals while out of the office, or checking access logs, can all be done from your phone alone (the Agent itself runs on your PC or server).
Windows and Linux are supported. The Agent is a runtime-free static single binary, provided for each OS, and installs with a one-liner. See the per-OS setup guide for details.
Yes. A Windows Agent is available and installs with a PowerShell one-liner (irm … | iex). Besides publishing web apps running on Windows, you can also use it to publish RDP (TCP canal, Pro and above). You can also register it as a Windows service so it runs resident, starting automatically without anyone logged on. See the Windows setup guide for the steps.
Yes. A Linux Agent is available and installs with a one-liner (curl … | sh). Besides web apps running on internal Linux servers, you can also publish SSH and databases (TCP canal, Pro and above). See the Linux setup guide for installation and running resident under systemd.
Yes. On Windows, run wirecanal service install -config wirecanal.json once in a PowerShell opened as administrator and it is registered as a Windows service (Agent v0.16.0 and later; see the resident-service steps in the Windows setup guide). It starts automatically at boot without anyone logged on, and if it stops it restarts automatically after about 5 seconds (uninstall with wirecanal service uninstall). For Linux, see the systemd template.
Yes. In proxy-only environments, just add one line — proxy_url — to the configuration file wirecanal.json. The behavior is deterministic and unaffected by environment variables (HTTPS_PROXY, etc.). See the wirecanal.json configuration reference for how to write it.
Yes. Add a single line — "lang": "en" — to the Agent's configuration file wirecanal.json and its startup messages and log output switch to English (the default is Japanese). Handy when placing the Agent on servers at overseas sites. See the wirecanal.json reference for configuration details.
No. WireCanal is a pure pass-through pipe that carries raw traffic as it is, so no configuration changes or code modifications are needed on the server you want to publish. Just place the Agent and one configuration file.
Most of what ngrok does (HTTPS publishing, TCP, custom domains, IP restriction, and so on) WireCanal can do too. On top of that, three things are different: ① relay infrastructure operated on servers in Japan — the entry point sits on domestic servers; ② eight kinds of access protection standard on all plans — IP / country / BASIC / Bearer / scheduled availability / path / auto-block / stealth; ③ an MCP gateway that lets you expose only the tools you choose from your in-house MCP server to AI. It works both as an ngrok replacement and as the entry point for AI integration. A side-by-side comparison on use cases, whether ports must be opened, fixed URLs, free tiers, data path, and setup length is on the comparison page.
Yes. Any TCP service can be published as tcp://jan000.wirecanal.net:<port> (Pro plan and above). The port is assigned automatically at creation and stays fixed for the life of the canal. See the tunnel page for details.
Yes. A single Agent can open multiple canals in one process (up to your plan's limit). You can also download one configuration file covering several canals (format: wirecanal.json reference).
Visitors accessing it in a browser see a notice page saying the site is currently offline (response codes for programmatic access such as APIs stay as before). Start the Agent again and the same URL simply resumes.
On the Premium plan, you can use the domain you own (e.g. app.example.co.jp) directly as the public hostname (HTTP / MCP canals). Follow the on-screen guidance to add one or two DNS records, and everything from automatic certificate issuance to connectivity verification proceeds automatically — you'll also be notified by email. You can detach or reassign it anytime. On the Free and Pro plans, you can use random names or reserved subdomains of your choice.
Yes. With an on-premises server and one canal (HTTPS), you can publish your company's website as it is. You can also bring your own custom domain (Premium). Certificates are issued and renewed automatically, so there is no upkeep after publishing.
On paid plans there is, in principle, no data transfer limit. On the Free plan, roughly 10GB per month is the guideline, and speed may be reduced if you exceed it. To keep usage fair and preserve network bandwidth, sustained, extreme high-volume traffic that significantly affects other customers (such as monopolizing bandwidth for long periods) may be subject to speed limits or similar measures. Some high-speed edge servers may also have a separate per-day transfer cap. See the pricing page for the per-plan list.
In principle, no. Lines are provided on a best-effort basis; because they are shared, actual speeds vary with other customers' usage. Sustained, extreme usage that significantly affects other customers may be subject to bandwidth limits.
It is the feature that publishes your in-house MCP server as a remote MCP URL that AI can use. One canal equals one remote MCP URL. MCP canals are available on every plan. See the MCP & AI integration page for details.
Two major differences.
① You can choose exactly which tools to expose. An ordinary tunnel is a plain pipe: connect your in-house MCP server and every tool on it goes straight outside. WireCanal's MCP canal stands in between as a gatekeeper that understands MCP. It starts in a deny-all state, and only the tools you allow become visible to the AI. Tools you have not allowed do not even appear in the tool list, so their very existence stays hidden from the outside. You can, for example, allow only read-only tools while keeping deletion and other operations blocked as a group.
② OAuth authentication for connecting with ChatGPT and Claude is built in. To connect an in-house MCP to the connectors in the web versions of ChatGPT and Claude, you would normally have to build and implement an OAuth authentication mechanism yourself. Publishing through a plain HTTPS tunnel leaves you stuck right there. The MCP canal has OAuth built in, so just enable it on screen and it connects to ChatGPT and Claude with no implementation work.
These two things are fundamentally impossible for a general-purpose tunnel that merely exposes a port.
Yes. Even if your in-house MCP server has 20 tools, per-tool exposure control lets you show the outside AI only the few you allow. The allowlist lives in your own configuration file on your side, so it can never be widened from the cloud provider's side (two-key). Destructive tools are blocked by default. For a walkthrough with actual screenshots, see Choosing which tools the AI sees.
You can set them from the screen. In the dashboard's tool-permission view, the tool names detected by the connected Agent appear as checkboxes; just pick the ones you want to expose and save. What gets saved, however, is only a "proposal" — it takes effect only when someone on your side runs the approval command locally (separation of proposal and approval). Screen operations alone can never change what your network exposes. The steps, with actual screenshots, are in Choosing which tools the AI sees.
The authority to decide which tools may be exposed rests with the configuration file on your own premises, which cannot be rewritten from the cloud side (the two-key structure). Edits from the dashboard also go through the separation of proposal and approval and take effect only after an approval operation on your side. Even if something went wrong on the cloud side, no tool can be added without your consent — this structure, together with activity records kept inside your network, gives you a form that can pass corporate security reviews.
No. WireCanal pipes raw MCP traffic as it is and passes paths through untouched. You only write the exposure mode and allowed tools in the Agent's configuration file — the MCP server itself is never touched.
An MCP canal can be registered as-is with any client that supports remote MCP — Bestllam / claude.ai / Claude Code / ChatGPT / Gemini, and more. For the web versions of ChatGPT, Claude, and Grok, OAuth authentication is built in, so simply enabling them as supported services connects them easily (no need to build an authentication mechanism yourself). For setup steps, see the ChatGPT, Claude, and Grok guides.
Yes. Create an MCP canal and enable ChatGPT as a supported service, and your in-house MCP becomes available as a connector in the web version of ChatGPT. See the screenshot-based ChatGPT setup guide for the steps.
Yes. Enable Claude as a supported service and your in-house MCP becomes available as a connector in the web version of Claude (claude.ai). See the screenshot-based Claude setup guide for the steps.
Yes. For each canal, incoming access (who, when, from where, and the result) is recorded and can be checked in the dashboard, via the API, and as CSV. Audit records stay inside your organization; WireCanal's cloud side never holds tool arguments or execution results (when you use a cloud AI, the requests and results needed for tool calls are exchanged between you and that AI service). Per-tool-call activity auditing with tamper detection is planned for the future.
Yes. With organization IdP integration (Lite plan and above), a single canal can be used by every member of a department, each from their own ChatGPT or Claude. Members just log in with their company account (Google Workspace, etc.) and authorize the connection themselves — no WireCanal account registration is needed. Who is allowed is controlled by the email domain the owner configures (e.g. example.co.jp). For setup, see the screenshot-based guide to sharing with your organization's members.
Yes. Organization IdP integration (Lite plan and above) works with OIDC-compliant identity providers, and Google Workspace works as it is. The authorization screen switches to your company's Google login, and only members of the organization on the allowed domain can pass (accounts outside the organization are refused). On the Google side, all that's needed is a one-time client registration — the steps are shown with actual screens in Step 1 of the guide.
Once the company suspends their Workspace account, that person's connection is revoked automatically within one hour (no action needed on the WireCanal side). Access is refreshed automatically every hour, and each refresh asks your company's identity provider whether the account is still valid. See the operations chapter of the guide for details.
No. The Agent never connects to any destination other than the forwarding destination you configured (fixed forwarding destinations). This structurally prevents the tunnel from turning into an open proxy inside your network and being reused as a pathway.
No. WireCanal is designed as a pure pass-through pipe that delivers traffic to your internal forwarding destination without touching its contents, and it does not store or record the contents of the traffic (request or response bodies). All that remains on WireCanal's side is header-level information such as access logs (when, from where, to which path, and so on). Every path is protected with TLS.
Passwords and keys entered for access protection (BASIC authentication, access keys, and so on) are used by WireCanal only for verification and are never passed to your internal forwarding destination. The login and authentication your internal systems already have keep working as before — going through WireCanal never doubles up or bypasses your authentication.
Yes. Besides scheduled availability (fixed to JST) and path restriction, you can configure eight kinds of access protection per canal, including IP / country / BASIC / Bearer / auto-block / stealth (available on all plans). See the security page for details.
Yes. For each canal, incoming access can be checked in the dashboard (and via the API) — up to the latest 1,000 entries depending on your plan (10,000 for Premium / Enterprise) — and downloaded as CSV. What is recorded is only connection metadata such as when, from where, and to which canal; the contents of the traffic (the data itself) are not recorded. Only the canal's owner can view the records, and older entries roll off automatically.
The Free plan has no time limit and lets you try the core features: 1 canal, MCP integration, and access protection. Setup takes just a few minutes following the per-OS setup guide. If you need paid features, subscribe from the pricing page or the plan sign-up screen.
There is no free trial of the paid plans. Please start with the Free plan — it has no time limit — to get a feel for the basics.
Pricing is listed on the pricing page (prices in USD; annual and monthly billing available). Payments from outside Japan are made in USD; if you are located in Japan, you are billed in Japanese yen at the yen prices shown on the Japanese page. The Enterprise Plan for departments and teams is individually quoted.
Yes. The "extra canal add-on" adds one canal at a time ($12.99/mo). See the plans page for details.
For corporate and departmental contracts, we offer the Enterprise Plan: an individually negotiated contract with seat-based use (multiple users) under one contract and invoice payment. Feel free to reach out via "Ask about the Enterprise Plan".
Yes. The Enterprise Plan supports seat-based use under one contract. An administrator invites members, so multiple users across a department or team can be managed under a single contract.
The Enterprise Plan supports invoice payment (bank transfer); closing dates and payment terms are negotiable, and card payment is also available. Payment for the Free through Premium plans is by card.
Yes. The Enterprise Plan offers bulk allotments of 100–1,000 canals. Well suited to publishing the many local servers across a department, together.
Yes. Under the Enterprise Plan, we can register and configure an original domain on your behalf as a paid service. If you don't have a domain yet, feel free to ask.
Yes. Anyone can sign up for free at app.wirecanal.com and start using it right away.
Sign-up is free. No credit card required — create your first canal right now.
Sign up free and get started
WireCanal