Skip to content

Member Access

Let teammates reach deployed machines as themselves. They run one command, approve a code in a browser, and get a certificate that expires on its own.

Summary

A person signs in with localport login. The command prints a code, they approve it in a browser, and a short-lived certificate lands on the machine they are working from. Nothing has to be copied to that machine first, so it works over SSH into a jump box.

Needs a fleet, which is on the Pro and Enterprise plans. See Fleets to create one.

How signing in works#

Signing in issues a certificate that lasts 8 hours and does not renew. When it expires, the person signs in again. Nothing long-lived is stored on the machine.

The certificate carries the person's username, never their email address. The username never changes, so a grant written for a colleague keeps working across every sign-in they make.

Sign in#

On the machine that will connect, run:

localport login

The command prints a link with the code already filled in, the plain address, and the code on its own:

  Open https://dashboard.localport.io/device?code=HBQX-4T2M
  or go to https://dashboard.localport.io/device and enter  HBQX-4T2M

  Waiting for you to sign in...

Open either one in any browser, on any device. The prefilled link is one click. The bare address plus the code is what works when the command is running over SSH and the browser is on your phone.

The dashboard asks you to confirm the code, then shows what is being requested. Select Sign in and the certificate arrives in the terminal a moment later. The command then prints where it was stored and when it expires.

Enter the code, check what is being approved, approve. The terminal picks it up by itself.

You can also approve without leaving the dashboard. The Connect over mTLS panel, reached from a device's Access button, has an As you tab that takes the code inline and hands back the command to run.

From then on, no credential flags are needed:

localport access https://device1-example.eu.localport.dev -p 3001

What the approval screen asks#

Read the screen before selecting Sign in. It shows the code in large type and asks whether it matches the one in your terminal, along with:

  • Requested from, the address the command was run from.
  • Team, when you belong to more than one.
  • Certificate lasts, the lifetime of what you are approving.
  • It will be able to reach, listing every fleet you already have access to and the devices on each.

Check that last section. When no fleet has granted you access, the screen says so, and the certificate you are approving will reach nothing until an admin writes a grant.

If the code on screen is different from the one in your terminal, or you did not just run the command, somebody else started the sign-in. Select Cancel. Nothing is issued, and there is nothing else to do.

Approving asks for a recent dashboard sign-in, so you may be prompted to authenticate again first. Cancelling never asks for anything. A code works once and is valid for a few minutes.

Why it works over SSH#

Nothing has to reach the machine beforehand: no token, no team name, no identity, no configuration file. The command generates a key pair locally, requests a code and prints it.

The terminal and the browser never have to be on the same machine, so this works where a redirect back to localhost cannot. The private key stays on the machine you ran the command on, and the approval is bound to that key, so only that terminal can collect the certificate.

Give a member access#

Signing in proves identity. It grants no access on its own.

On each fleet they should reach, open the Access tab, select Give access, and choose either:

  • Role, covering everyone who holds it. Joiners and leavers are handled by changing team membership, with no per-person edit.
  • Member, naming one person, for access the rest of their role should not have.

Use a Role grant wherever the whole group needs the same access. See Grants and Access.

When someone leaves#

Remove them from the team in Members. That single action drops their individual grants, revokes their sign-in certificates, re-evaluates every role and team-wide grant that covered them across every fleet, and ends their browser sessions. Live connections close.

Machine credentials are left alone, so a deploy-prod identity keeps working after the person who set it up leaves.

Their access log entries stay, so the record of what they reached outlives the account.

Turn command-line sign-in off#

Some teams want every credential issued by an admin. Team Settings has an Access section with a Command-line sign-in switch.

With it off, members cannot sign in from the CLI and need a setup key from an admin instead. Sign-ins already approved keep working until their certificates expire, so turning it off is not a cut.

The switch appears once your team has a certificate authority, which happens the first time you create a fleet.

Frequently asked questions#

How do I sign in to Localport from the command line?

Run localport login. It prints a code and a link, you approve it in a browser on any device, and a client certificate lands on the machine you ran it from. Nothing needs to be copied to that machine beforehand, and no flags are needed afterwards to use it.

How long does a sign-in last?

8 hours, and nothing renews it. Run localport login again when it expires. That is one command and a browser tap.

Does signing in give me access to anything?

No. It proves who you are. What you reach is decided by grants an admin writes on each fleet, and the approval screen lists exactly what your certificate will reach before you accept it. If that list is empty, you can sign in and still reach nothing until somebody grants you access.

Can I sign in over SSH, without a browser on that machine?

Yes, and it is what the flow is built around. The command prints a code, you open the address on your phone or laptop, and the certificate lands on the remote machine. The terminal and the browser never have to be on the same device.

How do I revoke a person's access?

Remove them from the team. That drops their individual grants, revokes their sign-in certificates, and re-evaluates every role and team-wide grant that covered them across every fleet. To keep them on the team but take away one fleet, remove or narrow the grant there instead. Both close connections that are open at the time.

Should I grant access to people or to roles?

To roles, wherever access should follow the org chart. A grant on Developers covers whoever holds that role today, so joiners and leavers need no edit on any fleet. Name an individual when one person needs something the rest of their role should not have.

What if I see a sign-in request I did not start?

Select Cancel. Nothing is issued and there is nothing else to do. Always check the address under Requested from and the code against your own terminal before approving. That check is what catches a sign-in somebody else started.

Can several people share one credential?

They can technically, and it removes the reason to have this. An access log that says deploy-shared reached a production gateway answers nothing during an incident. Each person signing in as themselves is what makes the trail useful, and it costs one command per working day.

Can I be signed in on more than one machine?

Yes. A laptop, a desktop and a jump box can each hold their own sign-in certificate at the same time, each with its own key and its own expiry. localport identity list shows what any one machine holds.

Does Localport store my name or email on the machine?

No. The credential record on disk holds your username, the team id and the team name, and nothing else about you. The username is what the certificate carries, what grants name and what the access log records, so no display name or address is ever sent to the machine or stored on it.

Previous Setup Keys Next CI/CD with OIDC