Your people.
Your servers. Your access.

Deploy and administer AccessHub, manage identities and server access, and configure Linux group and filesystem permissions.

Choose the right page

Administrators see the management pages. Ordinary website users use My account for their own access and security.

Appearance

Next release: use Appearance to select Light, Dark or System. System follows your device’s color preference. Your choice is saved in this browser and applies to sign-in, setup and workspace pages. Dark uses charcoal surfaces, soft white text and green accents, with the same layout and branding as Light. Terminal colors stay optimized for console use.

From Compose to a running website.

Use a Linux host with Docker Engine and Docker Compose 2.34 or newer, on amd64. Allocate capacity for the services, container images, logs and backups.

mkdir accesshub
cd accesshub
# Save the downloaded compose.yaml here.

docker compose up -d
docker compose ps

Network paths you need

Keep LDAP and enrollment private. Do not expose ports 389 or 8443 to the public internet.

Managed servers require network connectivity to the controller and individual enrollment.

Trust the installation. Claim the administrator.

1. Export the public website CA certificate

The default HTTPS certificate is issued by an installation-managed private certificate authority. Run this from the deployment directory:

docker compose exec -T web cat /data/caddy/pki/authorities/local/root.crt > accesshub-root-ca.crt

Transfer this public certificate securely to your browser device and trust it in the appropriate OS/browser certificate store after verifying it belongs to your installation. Never export or share the CA private key. Public-domain HTTPS is a separate configuration task; the default does not provide it.

2. Get the private installation setup code

docker compose exec api cat /run/secrets/installation_setup_token

Use the code in the initial setup screen to create your administrator account. It proves access to the Docker host and authorizes administrator creation. Keep it private; do not paste it into an issue or chat.

3. Sign in normally

After the installation is claimed, use your website username and password. Configure an authenticator where supported. A website password is not an SSH key, and is not automatically a Linux sudo password.

Accept your invitation

1. Open the private invitation supplied by your administrator.
2. Create your password. Follow the password requirements shown on the page.
3. If wanted or required, set up an authenticator: scan the QR code in your app and enter a fresh code to confirm.
4. If recovery codes appear, use Copy codes or Download codes and store them privately. Confirm that you have saved them.
5. Continue to sign in. Enter your username and password, then the authenticator code when requested.

The sign-in form stays hidden until account setup is complete. Recovery codes are shown once; each works once with your password. Never share your invitation, password, QR secret or recovery codes.

Next release: new passwords require at least 15 characters, a lowercase letter (a–z), an uppercase letter (A–Z) and a special character such as !, @ or #. Live checkmarks show these requirements and whether passwords match. The maximum length is 128 characters. Existing passwords remain valid for sign-in. Requirements are enforced when creating or changing a password. Passwords are not sent to a breach-check service.

Installing AccessHub or claiming the first administrator? Use the first-administrator setup guide instead.

Not all groups do the same job

Giving an AccessHub group the name “docker” does not create Docker's operating-system group or grant Docker access. The type of rule and its selected server/group determine what happens.

Create the right kind of account

1. Open Users → New user.
2. Choose the account type: website only, Linux identity only, or linked Website + Linux identity.
3. Enter the username and optional display name. For website accounts, choose the website role.
4. For a Linux identity, optionally select SSH access groups. Leave them empty if no server access is needed yet.
5. Create the user. If an invitation is generated, share it privately with the account owner.

A linked account connects website sign-in to a specific Linux identity. Matching names alone do not create that link. A website-only account cannot receive Linux group membership without a linked Linux identity.

Read a user's details

• Profile: website/Linux usernames, role, UID, primary group and identity link.
• Server access: effective SSH paths and whether enforcement is confirmed.
• SSH keys: add a public key or revoke an existing key. Never upload a private key.
• Website security: review website sessions, sign out sessions, or reset account setup.
• Lifecycle: control website sign-in and Linux login separately, and review archive/deletion requirements.

Disable the correct access

For deletion or restoration, read the confirmation scope carefully. Deleting website sign-in and disabling Linux login are separate choices; restoration does not automatically restore access.

Grant SSH access to a server

1. Make sure the person has an active Linux identity and an appropriate public SSH key.
2. In Access, create or open an access group and add the person.
3. Put the enrolled server in a server group. Use the server-group management view to add or remove servers.
4. Create an access policy connecting that people group to that server group. Review the selected groups before enabling it.
5. Wait for enforcement, then check the person's Server access or their My account → Server access.

The effective-access view explains which group → server-group paths grant access. If no path is available, check all parts of the rule rather than adding the same person repeatedly.

Revoke access

Remove the person from the access group, remove the server from the server group, or disable the relevant SSH policy. Check the effective result afterward. Managed console sessions are subject to revocation; unrelated external SSH sessions may remain open.

Delete a group

Open its management view and read Deletion blockers. Remove members and referencing policies—including disabled references—before deleting an eligible empty group. Deleting a group does not delete people, servers or their files.

Add and enroll a server

1. Open Servers and create the server record using its intended Linux/server name.
2. Open that server's Enrollment dialog.
3. Use Copy command. Run that exact command on the Ubuntu server you are enrolling, with administrator permission—not in the controller's terminal.
4. Use Issue token, copy the one-time token privately, and paste it only at the command's hidden token prompt.
5. Confirm the server/controller details requested by the tool. Wait for enrollment to finish.
6. Return to Servers and check authenticated agent contact. Add the server to the intended server group, then grant SSH access separately.

The website does not ask for a server's SSH password to push-install the tool. A server administrator runs the generated command. Obtain it only from your trusted AccessHub website; do not edit out its verification steps.

If the command or token expires

Reopen Enrollment to copy a fresh command. Issue a fresh token if required; a replacement invalidates earlier outstanding tokens. Keep tokens out of shell commands, screenshots and chat. If enrollment partially completed, follow the tool's resume guidance rather than deleting its protected receipt or creating duplicate server records.

Inspect operating-system groups

Open the server's OS groups view to review its reported local groups and operations. The separate Create local group action is for supported application groups. Check the name carefully before queuing it, then verify the server's result; protected or conflicting names are refused. A Linux group permission policy never silently creates a missing group.

If enrollment cannot connect, ask the installation administrator to check networking and trust. The operator reference covers those prerequisites. Do not bypass a browser certificate warning to obtain a command.

Add a person to a server's Linux group

1. Open Permissions → Linux group permissions → New group permission.
2. Give the policy a descriptive name.
3. Choose the people group, server group and existing Linux group name—for example, sudo.
4. Use Preview affected servers. Check who is affected and whether the Linux group exists on each server. Missing or unverified groups are not ready to apply.
5. Save the draft. A draft grants nothing.
6. Open Review and apply, inspect the proposed changes, and confirm activation.
7. Open View results. Wait for the server's membership result, not just an Active policy badge.

Remove or stop managing membership

Disable the permission and check its cleanup results. AccessHub removes only memberships it owns; another policy may still require the same membership. Keep membership and stop managing leaves it on the server but relinquishes AccessHub's ownership of its removal.

Inspect first. Change only what you intend.

Name/ID suggestions and recursive scope are next-release features. Published alpha.2 uses owner/group dropdowns and changes the selected path only.

1. Select the Server workspace.
2. Enter the absolute file/directory path, such as /opt/example/uploads.
3. Leave Include directory contents off for this path only. Turn it on before inspection if you want a recursive change.
4. Click Inspect path. Check the path, observed owner/group, permissions, and whether editing is allowed.
5. Type the owner and owning group. Suggestions contain names reported by this server. A unique numeric UID/GID turns into its name when you leave the field. Unknown or ambiguous identities cannot proceed.
6. Set the Owner, Group and Others checkboxes. For recursive scope, set directory permissions and file permissions separately.
7. Click Review changes. Check every proposed ownership/mode change and any skipped paths. Confirm only the intended scope, then apply once.
8. Wait for the server-confirmed result. Inspect again to confirm the actual current state.

The owner field changes the file's owner; it does not add an extra per-user permission entry. These settings do not grant SSH login or sudo.

Owner, Group and Others are different permission classes. Being able to read a file also depends on access through its parent directories. AccessHub inspects metadata; it does not read or edit the file's contents.

Recursive changes: directory and contents

The preview lists included and skipped paths. One owner/group is proposed for all included items, with a separate mode for directories and for files. File execute permission is not automatically enabled just because directories need traversal. Mixed file modes default to a proposed 0644; review whether that suits your application before applying.

• Off by default. Changing the scope requires a fresh inspection.
• Limit: 64 entries including skipped items, 16 directory levels, and bounded preview size/time. Oversized trees are refused, not silently truncated.
• Links, protected paths, special files and nested mounts are skipped without entering them.
• Unsafe included entries—such as extended ACLs, special bits, hard links or untrusted parents—block the whole apply.
• Changes are not atomic: interruption can leave some items changed. AccessHub does not automatically retry or roll back the operation.

Inspection only or uncertain result?

Supported targets are application paths below /srv, /opt, /var/www or /home—not those bare roots. Parent directories must initially be root-owned and not writable by their group/others. Protected identities and credential/configuration paths are restricted. Do not change a user's home ownership just to bypass a safety check.

For an uncertain operation, wait for the old execution to settle, then inspect the same scope again. Recursive uncertainty needs a new recursive inspection. Acknowledge current state records that review; it does not replay, undo or complete the original change. Decide any correction from the fresh observations.

Recent inspections and changes keeps past requests and results. Old observations can be stale; do not treat viewing history as a new inspection.

Manage your own connections and security

Server access

Open My account → Server access to see your permitted servers and connection options. Open only the server you intend to use and verify the Linux username. If a server is missing, ask an administrator to check your Linux identity, groups, policy and enforcement status.

SSH keys

1. Open the SSH keys tab.
2. Enter a useful label and paste the public key in the supported format.
3. Add it and check its fingerprint. Revoke a key you no longer trust.

Public keys identify your SSH credential; never upload the private half. A registered key does not create a new access policy.

Security

Use this tab to change your password, configure or disable your authenticator, and manage recovery options. Enter the current password and any requested verification factor. Save newly issued recovery codes privately when the page offers them.

Where the linked website/sudo password feature is enabled, changing your website password changes the password used for sudo too. MFA still protects the website; an authenticator code is not a Linux sudo password.

Open a terminal on an authorized server

Authenticator-only console confirmation is a next-release feature; published versions may request both password and authenticator verification.

1. In My account → Server access, choose the intended server's console.
2. If you have an authenticator enabled, enter a fresh six-digit code. Otherwise confirm your website password.
3. Connect, then verify the server prompt and Linux username before entering commands.
4. Use Close console when finished.

A code used to sign in cannot be reused for a console confirmation; wait for the next code. Recovery codes are not accepted for console confirmation.

Exiting the shell with exit or Ctrl+D closes the console and returns to the page beneath it. The console has a 15-minute idle limit and a 60-minute maximum session. After it expires or loses its connection, choose New console session and verify again. It opens a new session, not the old terminal. If your website session expired, sign in normally first.

Which password does sudo need?

Where shared authentication is enabled for a linked account, enter your current website password at the Linux sudo prompt—not your authenticator code. The server must also have granted sudo permission. Website-only accounts have no Linux sudo password, and installations without shared authentication must be checked separately.

Click inside the terminal to focus it. Selection is for copying text; be careful not to paste a command accidentally. New Linux group membership takes effect in a new console/SSH session, not necessarily the one already open.

Check what was requested and what finished

Open Audit trail to review recorded administrative actions and their outcomes. Read the Time, Action, Target, Result and Correlation columns. Compare timestamps and target details to the user, server or policy you were changing; related records can share a correlation identifier.

For a queued server action, also open its per-server operation result. “Requested” or an Active policy is not the same as a successful agent result. Audit history is retained when an eligible policy or identity is removed; deletion is not a way to erase the record.

Audit records are not a complete shell transcript. Check the specific operation rather than assuming all terminal activity appears here.

Live updates do not mean instant completion

Automatic updates are a next-release feature. Published alpha.2 uses manual Refresh.

The dashboard updates automatically when server results change, typically within about 5–15 seconds after the result is reported. Agent work may take longer. The indicator near Refresh shows whether live updates are connected, paused or using slower polling.

• Updates pause while editing, in dialogs, on private-code screens and while the page is in the background.
• If live updates are unavailable, slower polling is used. Manual Refresh remains available.
• After an application update, reload the website once to load its new scripts; refreshing data alone does not replace an old page.
• Expired or revoked website sessions require sign-in again.

Keep the data and the trust together.

The stack stores more than a SQL database: LDAP, credentials, signing keys, MFA material, certificates and console state also matter. Back up every named volume together, and retain the exact Compose file, deployment settings and image versions.

Stopped-stack backup

The supplied backup helper stops the stack, archives all named volumes with an integrity manifest and restarts it. Schedule a maintenance window. It requires Python 3 and permission to use Docker.

# Save backup.py beside compose.yaml first.
# The backup directory must be new, with a private parent.
sudo install -d -m 700 /var/backups/accesshub
sudo python3 backup.py backup \
  --project accesshub-five \
  --file compose.yaml \
  --directory /var/backups/accesshub/before-upgrade

If you use a custom project name, extra Compose files or an explicit environment file, pass those same inputs to the helper (--file can be repeated; --env-file .env is optional). Use a new destination for each backup. Archives contain secrets: protect, encrypt and store an off-host copy. Check that the helper reports a complete backup; a partial directory is not a valid recovery set.

Restore & upgrade checklist

1. Test restoration into a new, stopped project using the backup's original Compose and complete image set. The helper refuses to overwrite existing volumes.
2. Review ports and Docker subnet conflicts before starting a restored copy; don't run it alongside the original with the same network bindings.
3. For an upgrade, keep the old Compose/settings and a complete backup, pull the chosen versioned images, stop services, then recreate using the same project name and existing volumes.
4. Verify health, normal sign-in, identities, enrollment trust and a permitted console connection before ending maintenance.

Review the target release’s migration and rollback requirements before upgrading. Schema changes may require restoring the complete backup to roll back.

Private LDAP / enrollment certificate renewal

docker compose exec api python /app/portable/init_tls.py --renew
# After verifying renewal succeeded:
docker compose restart api directory
docker compose up -d --wait

This renews private service certificates through the API initializer. The web proxy manages its own HTTPS certificates. Keep both sets of persistent trust volumes; this command does not configure public ACME certificates.

docker compose ps
docker compose logs --tail=100 api
docker compose logs --tail=100 directory
docker compose logs --tail=100 web

What should I do next?

Report a bug

Next release: choose Report a bug to send feedback to AccessHub’s developer. Reporting is available only when your installation has a configured support destination and you are signed in.

1. Take a screenshot, record a short screen clip, upload an existing file, or continue without an attachment.
2. Enter a summary and describe what happened, what you expected, and how to reproduce it.
3. Review the report and attachment for private information, then choose Submit bug report.

The browser asks which screen, window or tab to capture. A screenshot captures one frame; recording stops after 30 seconds and has no microphone audio. Attachments must be PNG, JPEG, WebP, WebM or MP4, up to 5 MB. Remove an attachment to discard it. Closing the dialog stops capture.

AccessHub does not automatically collect logs, credentials or screenshots. Do not include passwords, setup tokens, recovery codes or private keys. If submission is not confirmed, check with support before resubmitting to avoid duplicates. Reporting requires a reachable support service; a configured destination alone does not guarantee delivery. Reports are not silently queued or sent to a fallback destination.

First-time setup screen

In the next release, first-time setup verifies your private setup token before showing administrator username and password fields. Choose Continue to setup, create the administrator, then sign in. Token verification alone creates no account. Existing installations continue to sign-in without repeating setup.

Reviewing reports in the developer inbox

The separate support inbox is for the AccessHub developer. Sign in with the inbox password, search or filter reports, and select a report to read it. Screenshots open in the page and can be enlarged; screen recordings play directly with video controls. No attachment download is required.

Use New, Reviewing and Resolved to track progress. The Cloudflare support version also includes Ready: the developer has tested the fix and included it in a production image. That version is prepared for deployment and is not yet a live public service. The visible inbox checks for new reports automatically. Report lists and attachment previews require an operator session; a submission credential cannot read them. Signing out ends access to previews.

Versions and availability

The published deployment package is 0.2.0-alpha.2. It is an alpha release for private-network evaluation, not a production-stable release.

All images use the ghcr.io/saiedawad namespace. Components are versioned independently: an unchanged dependency does not need a new tag for every release.