// documentation

Using iBridge

Quickstart

You need an IBM i account. The public test system PUB400 gives you one free: sign up there, and PUB400 emails you a user profile and password.

Then open the app, go to SQL Studio, enter host pub400.com, port 2222 and your credentials, and press stay signed in. Pick a sample on the left — or write your own SQL/CL — and run it. SQL comes back as a table, display CL as clean text, and interactive CL opens the live terminal.

Sessions

Signing in opens one real TN5250 session on the iBridge backend and keeps it open. Every run reuses it, so there is exactly one sign-on no matter how many commands you run — which also means iBridge never burns through your profile's failed-sign-on allowance. Sessions expire after about 10 idle minutes (any run refreshes the timer), and disconnect signs off on the IBM i itself.

Your password is used only at the moment of sign-on. It is never stored, never logged, and the session token never leaves an httpOnly cookie in your browser. If you skip signing in, runs still work in one-shot mode: one sign-on per command, using the credentials in the form.

The terminal

When a command opens an interactive display — WRKUSRJOB, WRKACTJOB, menus, job logs — iBridge hands you that exact screen, live. The input boxes are not drawn by guesswork: the host's own 5250 field definitions say where each field starts and how long it is, and the terminal renders one input per field at those coordinates.

Type into the underlined fields (an option next to a job, a value on a prompt screen), then press ENTER or an F-key. All edited fields travel with the key, exactly like a hardware terminal, and the answering screen comes back with its own fresh field map. Invalid options get the host's own error messages — because it is the host answering.

SQL & CL rules

SQL is read-only. Only SELECT, VALUES, WITH and EXPLAIN statements run; anything that writes is rejected before it reaches the system. Table functions such as QSYS2.ACTIVE_JOB_INFO need their TABLE(...) wrapper, as on any IBM i.

CL passes a safety denylist. Display and work-with commands are welcome; destructive verbs are blocked. Runs are rate-limited per visitor, and hosts are checked so the tool can't be pointed at private or loopback addresses. If any connection door rejects your password, the run stops there — iBridge never tries a second door with the same credentials.

REST API

Beside the console, iBridge ships a working customer + order REST API: key auth via the x-api-key header, validation, server-computed totals, rate limiting, and a machine-readable OpenAPI spec. Try it live in the API Console — the demo key is shown there. The sandbox store is in-memory and resets on cold starts.

Keyboard

Press ⌘K (or Ctrl+K) anywhere in the app for the command palette: jump between sections, load any sample or saved query into the editor, open the terminal, or disconnect — without touching the mouse. ↑/↓ navigate, Enter selects, Esc closes. Inside the terminal, pressing Enter in a field sends ENTER to the host.

Known limits

The backend runs on a free tier that sleeps when idle, so the first sign-in after a quiet stretch can take a minute or two — and if the backend host restarts, live sessions end with it (the app will tell you the session expired rather than pretend otherwise). One session serves one browser; the terminal is a single 24×80 screen at a time.

Roadmap

Phase A — shipped: the app shell, navigation, system switcher, command palette, landing page and these docs. The connection engine underneath did not change.

Next: accounts with roles and an encrypted connection vault (B), audit log and command policies (C), connection profiles for many systems (D), the library/object explorer and live dashboards (E), a versioned platform API (F), an always-on backend (G), and an AI copilot with watchers (H).