Security
Built so you can hand it the keys
OpsNexa Online reaches your servers, clusters, repositories and cloud accounts. Here is exactly how that access is kept apart, kept small, and kept on record.
Architecture
Your company, kept apart
Every company that signs up gets its own OpsNexa Online, not a row in a shared one.
- Its own hub, at its own address, running separately from every other company’s.
- Its own database and database user. No company’s user can even connect to another company’s database.
- Its own encryption key for the credentials you save, kept encrypted by the service that runs it.
- Its own network rules. Addresses you type in (webhooks, monitors, servers, git) must be on the internet: the hub can’t be pointed at our internal services, the cloud’s metadata service or another company.
- Backed up daily, with the last 14 days kept.
yourcompany.opsnexa.onlineWhere your code and data live
OpsNexa Online runs your software on your machines, not ours.
Apps run on your servers
Apps are built and run on servers you connect over SSH, or on your Kubernetes clusters with images pushed to your registry. OpsNexa Online never builds or runs your code on its own machines.
Databases stay with the app
App databases run next to the app on your server, on a private network only that app can reach. Backups are kept by your OpsNexa Online and can be downloaded or restored at any time.
Or in your own cloud
Larger companies can run OpsNexa Online in their own Kubernetes cluster or virtual machine, with their own database. Nothing calls home and nobody at OpsNexa Online has access. Run it in your own cloud
Private networks, nothing opened
For machines without a public address, a small agent inside your network connects out over HTTPS. The agent decides which addresses may be reached, and never cloud metadata or loopback unless you list them.
Credentials, kept small and out of sight
OpsNexa Online asks for the least access each feature needs, and tells you exactly what that is.
No cloud keys at all
AWS, Google Cloud and Azure trust your OpsNexa Online’s own identity instead of a stored key: it assumes a role you create and gets credentials that last an hour. Delete the role to cut access. How it works
Read only, per connection
Every platform connection is read only unless you allow changes, and the form lists exactly what each choice does and needs. A read-only connection can’t remove access, clean up or rotate anything, whatever anyone clicks.
Encrypted, never shown again
Passwords, tokens and keys you save are encrypted at rest and never shown back once saved. Secret app settings are hidden in logs, timelines and anything sent to an AI model.
Tokens that expire
The GitHub App uses one-hour tokens tied to no person. Service tokens for pipelines have one job, an optional list of apps, and always an expiry.
Leaked keys found
Keys in code, git history, build logs and visible settings are found daily. OpsNexa Online stores a fingerprint and a masked preview, never the secret itself.
Host keys pinned
A server’s SSH host key is pinned on first contact, so a machine pretending to be your server is refused.
Your own key, replaced in a click
An agent’s token is stored hashed; a new install command replaces it and disconnects the old agent at once.
Changes you can see coming, and undo
The features that change things are built to be careful.
Plans before actions
Offboarding, cleanup, key rotation, access reviews and least-privilege changes show every step first. Nothing happens until an admin confirms.
Review-only by default
Cloud cleanup, accepting drift and right-sizing start switched off. An admin turns each on when ready.
Undo where possible
Data is backed up before it’s removed, policies are added before broad ones are taken away, and most steps offer Undo.
Fixes as pull requests
Code and infrastructure fixes are pull requests. Nothing reaches your branch until someone merges it, and your own checks run first.
Approvals for production
Production deploys can require approval from an admin or team lead, never the person who asked.
Never your own lock-out
Offboarding never removes the credential OpsNexa Online uses or your own account; admins can always sign in with a password if single sign-on breaks.
Who did what, on record
Sign-in that fits your company, and a log your auditor will like.
Single sign-on
Google Workspace, Microsoft Entra ID, Okta or any OpenID Connect provider. By default only people you invite can get in.
Two-step sign-in
Any authenticator app, with recovery codes. Admins can require it for everyone. Every signed-in browser is listed, with Sign out.
Roles
Tester, sandbox, developer and admin, plus optional team permissions so developers change only what their teams own.
Audit log
Every change with who made it, how (browser, token or AI assistant), whether it worked and from where, including sign-ins and downloads. Kept for a year, exportable as CSV.
AI with care
AI features are optional extras. Secret settings are replaced before logs are sent to a model, and assistants act with their person’s permissions, never above developer.
Your own data, any time
Download database backups, access exports and the audit log whenever you need them.
Found a security problem?
Please tell us at security@opsnexa.online. We’ll confirm we got it, keep you posted while we fix it, and credit you if you’d like.
Questions from your security team?
We’re happy to go through how OpsNexa Online handles your access and data.