Devopper

Every server operation, recorded.

Devopper is a server-management console for companies that run servers for other people. Add your servers once. From then on every command, deploy, certificate and credential goes through Devopper and ends up in one log: who asked for it, what ran, and what came back.

Create your workspace Sign in

Hosted workspaces are available now. Hybrid custody, with the vault on your own server, is coming soon.

60 seconds: the problem, and how Devopper answers it. Plays silently on a loop.
Read what the video says

47 servers, 12 projects, 6 people with root, and one of you. No control, and no time: who changed nginx on web-2, which SSH key is that, did the deploy finish, where is the database password, who still has root. Six hours a week per developer, over 300 hours a year, lost to server chores. What if every action went through one place? Devopper records every server operation: who asked, what ran and what came back, with failed attempts kept next to the retry. Passwords and keys live in a vault, never in a log, and you unlock only the servers you need for as long as you need. Describe an application once in the Apps wizard and get every environment, in minutes, not days. Devopper: every server operation, recorded.

What gets recorded

The log is a tree. A prompt is what someone asked for, the task under it is the work, and each step is one command with its exact output and exit code. A failed attempt stays in the log next to the retry.

  • prompt Put shop.example.com on web-2, proxied to port 3100 maria, 14:02, from 203.0.113.7
    • task Create the nginx site for shop.example.com 3 steps, 41 s
      • step Write the site file and test the configuration exit 1

        nginx -t

        nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/sites-enabled/shop.example.com:14
      • step Fix line 14 and test again exit 0

        nginx -t

        nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
      • step Reload nginx exit 0

        systemctl reload nginx

        (no output, 0.3 s)
One thread from the operations log. The first attempt failed on a typo; it stays in the record with the retry, because the log is the history, not a summary.

One console for the whole job

Each area does its own work and writes to the same log and the same vault.

  • Operations log

    Prompt, task, step. Every row keeps the exact command, its output, its exit code, who ran it and from where. Failed attempts are kept, not tidied away.

  • Credentials vault

    Passkeys (WebAuthn with PRF), authenticator codes and a recovery key. A sealed vault means that after a restart the server holds no usable key until a person unlocks it.

  • Websites and certificates

    nginx sites found by scanning. Every TLS certificate on every server, with its expiry date, where it is used, and whether the private key on disk belongs to it.

  • Databases

    Connections found by scanning the server. A read-only SQL console for operators; every statement is an operation, result rows are never logged.

  • Repositories and pipelines

    GitHub repositories with CI/CD pipelines delivered as pull requests, and FTP deploy accounts for the pipelines to push into.

  • Scheduled jobs and backups

    Real cron entries with results posted back. Encrypted backups to storage targets such as Dropbox, S3 or SFTP; the decryption key never sits on the server.

  • Domains and cloud accounts

    DNS at GoDaddy changed through Devopper, with before and after in the log. Azure accounts connected read-only: inventory, nothing changed.

  • Terminal and AI Pilot

    A web terminal over the server's own login. In AI Pilot the AI plans and the person runs every command, under guard rails that refuse fatal commands. Access grants lend one server to an outside AI session for a while; a DevOps MCP channel takes requests from developers' Claude Code sessions.

How it works

  1. Sign up

    Create a workspace for your company and invite the people who run servers. Each person signs in with a passkey or an authenticator; the workspace gets a recovery key that only you keep.

  2. Add a server

    Give Devopper an SSH key and the server's host fingerprint. It checks the connection, then scans the server: sites, certificates, databases, services, open ports.

  3. Every action is recorded

    Deploys, DNS changes, SQL statements, terminal sessions and AI Pilot runs now go through Devopper. Each lands in the log with its command, output and exit code, and every secret it needed came from the vault.

Deployment models

The difference between the three is who holds the keys.

  • Hosted

    Available now

    Everything runs on Devopper's servers, and your secrets live in Devopper's vault, sealed by your passkeys and your recovery key.

  • Hybrid

    Coming soon

    The app runs on Devopper's servers, but the vault and every action that needs a secret run on a gateway on your own server, so keys never leave your control.

  • Self-hosted

    Later

    The whole console runs on your infrastructure; Devopper ships the releases and you hold everything, keys and log included.

Built for people who run servers for others

When the servers belong to a client, the log is the answer to "what did you do, and when".

Agencies
Several clients, many servers, one workspace per client with its own log and vault.
Studios
Hand a site over with its complete history instead of a page in a wiki.
Consultants
Lend one server for a day with an access grant, and take it back without rotating keys.
Product teams
Deploys arrive through pull requests, and every deploy sits in the log next to the change that caused it.
Create your workspace Sign in