Questions people ask before they move a fleet

No, and we commit in writing never to. Enrollment has no price on it on Pro, Business or Enterprise: the device ceiling in the code that runs the service is set to infinity for all three, and the only device cap anywhere is the 14-day trial, which stops at 25. What the plans count is how many sessions are open at the same moment. The pricing page carries the commitment.

Neither plan counts technicians. The ceiling is on sessions open at the same moment, so the number to estimate is how many of your 40 are connected during your busiest hour. Pro allows 25 at once and Business allows 100. The trial's own ceiling is 5, which is enough for a pilot, so if you are not sure, tell us what your busiest hour looks like and we will tell you which ceiling covers it.

Nothing is deleted. Your account keeps its devices and its audit log, and the trial takes no card, so nothing is charged either way. Picking a plan carries on with the devices you already enrolled still enrolled, under the same names and with the same audit history behind them.

The same $49 on Pro or $199 on Business. The five thousandth machine costs what the first one did. The number worth checking at that size is how many technicians are connected at once.

No. There is no seat count in any plan and no per-operator charge, so hiring a technician does not move the bill. Single sign-on is on every plan, which is what makes adding and removing people something you do in your identity provider and nowhere else.

Paid plans are billed by card through Stripe. If you need an invoice, a purchase order or annual terms, write to support@jssh.io and we will set it up by hand. Enterprise works the same way.

Yes, and the contract you accept says how. Section 9.4 of the Terms gives you at least 30 days' notice, and a change applies from your next billing period after that notice period ends. If you want a longer notice period or a fixed term written into your agreement, that is a conversation we are happy to have before you sign.

What cannot change is which number the bill is computed from. We will never charge per enrolled device, and that one is structural rather than generous: there is no cost driver behind enrollment, so there is nothing there for us to start metering later.

It works behind CGNAT, because the device dials out and nothing needs a public IP. Where UDP is blocked in both directions the session runs over TLS on 443, which we measured at about 33 ms with pf on one end and iptables on the other. jssh-agent doctor on the device, and jssh doctor on a technician's laptop, print the exact line to send to whoever runs the network.

"You cannot forward ports at all behind CGNAT."

A site whose only route out is an explicit HTTP proxy. The agent's relay connection does not speak HTTP CONNECT today, so it needs a direct allowlist entry for app.jssh.io on TCP 443. This is the one answer worth checking before you count a site, because the diagnostic can look green on a proxy-only network while the device never appears. Count how many of your sites are proxy-only before you plan the rollout.

1 Send them the security page. It needs no login, it carries no pricing, and question 02 on it is the exact list of destinations to allow, with text for a change ticket.

If the machine is off or its link is down, nothing reaches it, and we do not claim otherwise. What jssh removes is the other half of that call, when the machine is alive and only unreachable because you have no route to it. The device dials out on its own and reconnects when the link comes back. The dashboard shows when each device was last connected, and the diagnostic prints what the network is blocking.

This is the shape jssh is built for. Each customer can be its own organization, with its own devices, its own access rules and its own audit trail, so the export you hand one customer's auditor holds that customer and nobody else. A technician can be given access to one customer and to nothing else in the fleet.

The bill does not move when you take on a customer. There is no device counter in the billing at all, so there is no licence to reprice when a site grows, and nothing to explain to a customer who added forty machines. What you count instead is how many of your technicians are connected during your busiest hour.

For a fleet you inherited, mint one enrollment token per customer, cap how many machines it may admit, give it that customer's tags, and push the install line through whatever already reaches those machines. Both commands are here.

Yes. The agent goes into the firmware image (a Yocto or Buildroot recipe, or a package in your own build), and units enroll on first boot with a manufacturing token that carries the tags you want that batch to have. Every unit you ship is supportable the day it lands on a customer's network, without asking that customer to open anything.

It is one static binary, 4 to 5 MB, with no runtime to add and nothing to resolve against the device's own libc, so it does not change what your image has to contain. Updates are signed, staged A/B and roll back on their own. There is no per-device cost eating your BOM margin at any volume. If you want to talk through firmware integration, write to us.

The properties a questionnaire asks about are architectural here rather than configured, which is the difference between a control that holds and a control that holds until somebody changes a setting.

• Least privilege: per-device, per-session authorization, and no network between devices at all. There is no route to disable because nothing was ever wired.
• Strong identity: devices hold an Ed25519 keypair and we store only the public key; operators come through your own identity provider over OIDC.
• Enforcement at the resource: access rules are enforced by the agent on the device, so a rule cannot be talked into opening a database port.
• Evidence: every session writes a row with the operator, the device, the start, the end and the source IP. When the questionnaire comes, you answer with a filtered export.

The full argument, with the drawing and the destination table, is on the security page.

The operator identity, which comes from your identity provider when SSO is configured, the device, the start time, the end time, from which the duration follows, and the source IP, plus which services that session opened and which ones it tried and was refused.

Filter by operator, device, action or date range, then export what you filtered, as CSV or JSON. The evidence sits in your own account, so answering does not start with a ticket to us.

started_at,ended_at,closed_clean,close_state,action,actor_type,actor_id,device_id,client_ip,detail"2026-03-11T14:02:18.441Z","2026-03-11T14:38:55.219Z","true","","session.open","user","usr_4c1f9ba27d0e4a6f9b3c85d21e7f60a4","dev_9f2c41b7d6084e5aa3c17f20b8e94d63","203.0.113.24","{""services"":[""rdp""]}""2026-03-14T09:41:02.905Z","2026-03-14T09:52:47.663Z","false","","session.open","user","usr_7e5b02c9a1d84f37b6c0e2915d4a83f1","dev_9f2c41b7d6084e5aa3c17f20b8e94d63","198.51.100.7","{""services"":[""rdp""],""deniedServices"":[""ssh""]}""2026-03-22T23:11:36.104Z","","","no-close-recorded","session.open","user","usr_4c1f9ba27d0e4a6f9b3c85d21e7f60a4","dev_9f2c41b7d6084e5aa3c17f20b8e94d63","203.0.113.24","{""services"":[""rdp""]}"

Start times are exact. End times are measured on our side, and when a laptop slept or a network dropped, the row records that the session lasted at least that long. The close_state and closed_clean columns are where that distinction lives, so you can tell a reviewer which rows are exact and which are floors.

One export writes up to 5,000 rows. When a filter matches more than that, the file says so in its own last line rather than trimming quietly: the CSV ends in a truncated comment carrying both counts, and the JSON carries total and exported. The remedy is a narrower date range, and the file tells you that you need one.

Session content is not stored on any path, and we do not measure session traffic volume on any path either. The Privacy Notice commits to both in writing and carries its own date, which is the one to cite if this goes into a procurement pack.

Audit rows are retained as long as the organization exists. There is no thirty-day window and no retention tier, so the answer to "can you still show me March" does not depend on what you pay.

Adding a technician, changing an access rule, issuing an enrollment token, revoking a device and killing a live session each write their own row, under the same filters and into the same file. A session that is open right now can be ended from the same page, and revoking a person or a device cuts the sessions they already have open.

Each customer can be its own organization, with its own devices, its own access rules and its own audit trail, so the export you hand one customer's auditor holds that customer and nobody else.

Neither plan counts technicians. The ceiling is on sessions open at the same moment, so the number to estimate is how many of your 40 are connected during your busiest hour. Pro allows 25 at once and Business allows 100. The trial's own ceiling is 5, which is enough for a pilot, so if you are not sure, tell us what your busiest hour looks like and we will tell you which ceiling covers it.

Without a running plan you cannot open a session or enroll a device, so access through jssh stops until you start one. Your data and your enrolled devices stay in the account, and a plan picks up where you left off. Nothing about the machines themselves changes, for the same reason nothing changed when you started: they keep their own sshd, their own host keys and their own users.

No, and we would rather you did not. The agent listens on nothing and holds one outbound connection, so it coexists with whatever tunnel or vendor agent is already on the box. Enroll a few sites, run both for a billing cycle, compare what your technicians actually reach for, then let the other subscription lapse at renewal. How that looks in practice.

No, and we will not imply one. There is no SOC 2 report today and no audit in progress that we would be entitled to name. What a reviewer gets instead is the security model written out, the isolation drawing, the measured numbers with their method, and a Data Processing Agreement that is published rather than negotiated per deal.