Managing shared credentials, API keys, database passwords, and infrastructure secrets is a constant challenge for technical teams. Spreadsheets create uncontrolled copies, chat messages are difficult to revoke, and personal password managers do not always provide the project-level access controls a team needs.
SecurityBox is a Dockerized, self-hosted team password manager and key management system designed for project secrets, granular permissions, application tokens, and infrastructure you control. This tutorial walks through deployment, first-time security, company and project setup, Alice and Bob access rules, API automation, and optional LDAP integration.
Prefer to watch? Follow the complete eight-minute SecurityBox video tutorial below.
Watch the SecurityBox tutorial on YouTube
What you will configure
- A self-hosted SecurityBox and MariaDB deployment
- A hardened system administrator account
- SecurityBox licence activation for organization features
- Company, user, membership, and project boundaries
- Per-secret Read and Edit permissions for Alice and Bob
- One-time API tokens for applications and CI/CD workflows
- Optional LDAP or Active Directory authentication
Step 1: Deploy SecurityBox with Docker Compose
Create a private deployment directory and save the following as compose.yaml. Replace every example secret with a unique, randomly generated value before starting the stack.
services:
mariadb:
image: mariadb:11.4
container_name: securitybox_db
restart: unless-stopped
environment:
MARIADB_DATABASE: securitybox
MARIADB_USER: securitybox
MARIADB_PASSWORD: replace-with-a-strong-database-password
MARIADB_ROOT_PASSWORD: replace-with-a-different-root-password
volumes:
- securitybox_db:/var/lib/mysql
healthcheck:
test:
- CMD
- healthcheck.sh
- --connect
- --innodb_initialized
interval: 5s
timeout: 5s
retries: 20
securitybox:
image: ssiroos/securitybox:latest
container_name: securitybox
restart: unless-stopped
depends_on:
mariadb:
condition: service_healthy
ports:
- "8080:8080"
environment:
ConnectionStrings__MariaDb: "Server=mariadb;Port=3306;Database=securitybox;User=securitybox;Password=replace-with-a-strong-database-password;Connection Timeout=5;"
SeedSaUser__Password: "replace-with-a-temporary-admin-password"
PasswordVault__MasterKey: "replace-with-a-long-random-vault-master-key"
Licensing__StorageKey: "replace-with-a-different-long-random-storage-key"
volumes:
securitybox_db:
Start SecurityBox and confirm both containers are healthy:
docker compose up -d
docker compose ps
docker compose logs --tail=100 securitybox
The application listens on port 8080. Keep the dashboard private behind a firewall, VPN, or authenticated HTTPS reverse proxy. Protect the Compose file because it contains sensitive bootstrap values, and back up the MariaDB volume using an encrypted backup process.
Step 2: Complete first-time sign-in and administrator security
Open http://<server-ip>:8080 from a trusted administrator network and sign in with the system administrator account and the temporary password configured for the deployment.
SecurityBox requires the seeded administrator password to be replaced before normal use. Choose a unique password, store it in a separate trusted administrator vault, and do not share the system administrator account between team members. After the first sign-in, create named accounts for routine work so actions remain attributable.
Individual users can use their personal password area without organization features. Company projects, collaboration, and directory capabilities require the appropriate licence.
Step 3: Activate your SecurityBox licence
- Open the Admin Panel and select License Status.
- Copy the installation’s device identifier.
- Register that device through the PWAApps licence portal.
- Copy the signed licence token into SecurityBox and save it.
- Confirm that the licence status changes to active and the required organization features appear.
Treat the signed licence token as sensitive configuration. Keep it out of public repositories, tickets, screenshots, and chat history.
Step 4: Create users, a company, and memberships
Open User Management and create named accounts for your team. For this example, create Alice and Bob with temporary passwords and active status. Require both users to replace temporary credentials through your normal onboarding process.
Next, open Companies and create an organization such as Tutorial Company. A company forms the boundary for its projects and members. Open the company membership page and add Alice and Bob before assigning either person to a project.
If your environment already has a central directory, you can configure LDAP later instead of maintaining every account locally.
Step 5: Create a project and share one password safely
Create a project such as Tutorial Project, document its owner or environment in the description, and add Alice and Bob as project users.
Project membership and password access are deliberately separate controls. Adding a user to a project does not automatically expose every secret inside it. This supports least-privilege access and makes reviews clearer.
Create a database credential with a descriptive title, service URL, username, and password. Then open the password-sharing controls and grant:
- Alice — Read: Alice can view or copy the credential but cannot change it.
- Bob — Edit: Bob can use the credential and update its protected fields.
Use the same pattern for API keys, service accounts, recovery codes, and customer credentials. Grant only the permission each person needs, review access periodically, and revoke it when responsibilities change.
Step 6: Generate an API token for automation
SecurityBox can also provide narrowly scoped secret access to applications and automation:
- Create a project access token with a description that identifies its workload and owner.
- Copy the generated bearer token immediately. It is displayed only once.
- Store it in the consuming platform’s protected secret store—not in source code or a Compose file committed to Git.
- Explicitly grant the token access only to the passwords or secrets the workload requires.
- Send it to the SecurityBox API with the
Authorization: Bearer <token>header.
If a token is lost or exposed, revoke it and create a replacement. A clear token description and narrow secret permissions make rotation and incident response much easier.
Step 7: Optionally connect LDAP or Active Directory
Licensed environments can connect SecurityBox to an LDAP-compatible directory, including a directory service managed through NetSmart. In the Directory Login settings, provide the directory host, port, Base DN, and login template required by your environment.
Use encrypted LDAP transport where available, validate certificates, and test with a non-administrator account before enabling it broadly. Directory authentication centralizes identity, but SecurityBox project and per-secret permissions should still define what each authenticated user can access.
SecurityBox best practices for teams
- Keep SecurityBox private and terminate browser access with HTTPS.
- Use a long, random vault master key and protect it separately from database backups.
- Back up the database and test restoration on a schedule.
- Create named user accounts instead of sharing administrator credentials.
- Separate project membership from access to individual secrets.
- Grant API tokens only the secrets required by one workload.
- Revoke access promptly during offboarding or role changes.
- Rotate credentials after suspected exposure and review access regularly.
- Update container images after reviewing release notes and taking a backup.
Take control of team passwords and secrets
SecurityBox gives development, DevOps, IT, and infrastructure teams a self-hosted place for encrypted passwords, API keys, database credentials, project access, and application tokens. The result is a clearer alternative to scattering secrets across spreadsheets, chat messages, source repositories, and personal vaults.
Set up your self-hosted team password manager with SecurityBox