Building a Bot With Someone Else — Collaborate in the Repo, Not the Panel

If two of you are building a bot together, know this up front: an application has exactly one owner, and there's no way to share access to it. No teams, no collaborators, no read-only seats. That sounds like a problem and mostly isn't, because the fix is the setup you'd want regardless — collaborate on the repository, and let CI do the deploying. Then nobody needs panel access to ship a change, and the one thing that genuinely requires the owner is the small set of operational actions: secrets, quotas, and restarts.

What single ownership actually means#

Every application belongs to one account. That account can see its logs, change its environment variables, restart it, resize it, and delete it. Nobody else can do any of that, and there's no mechanism to grant a second person partial access.

So the question isn't "how do we share the app" — it's "what actually needs the app, and what only needs the code?"

Most day-to-day work sits in the top rows.

Make deploys come from the repo#

The pattern that makes single ownership a non-issue: the owner sets up a deploy remote once, stores it as a repository secret, and a CI workflow pushes to it whenever the main branch changes.

After that, shipping is merging a pull request. Your collaborator never touches the panel, never needs the owner's credentials, and can deploy by doing the thing they were already doing.

That's better than sharing an account even where sharing is possible, for the usual reasons: changes go through review, every deploy is tied to a commit, and you can roll back to a known tag rather than reconstructing what someone did by hand.

Two details matter for a shared setup:

• Serialize deploys. Only one push per app is accepted at a time, so use a concurrency group or two merges landing together will race and one will fail.
• Use immutable tags if you deploy by image, so "which version is live" has an answer everyone can see.

What still needs the owner#

Be realistic about the remainder, because it's the part that creates a bottleneck:

• Secrets. A new API key has to be added by the owner as an environment variable. If your collaborator is adding a feature that needs one, that's a handoff.
• Logs during an incident. They can't look. In practice this means the owner is the one who debugs production, or pastes the relevant log into your issue tracker.
• Restarts, resizing, volumes, ports. All owner-only.

If that bottleneck is painful, the honest options are limited: either the owner stays responsive, or you both use one account — which means sharing credentials, with everything that implies. I'd rather not recommend shared logins; a password two people know is a password neither can rotate confidently. If you go that route, at least make it an account created for the project rather than someone's personal one.

Reduce what only the owner can see#

You can shrink the bottleneck with a few habits:

• Log to stdout with enough context that a pasted excerpt is actually useful. One startup line naming the version, and an identifier per operation, does most of the work — what to log.
• Push errors somewhere you both see. A bot that reports its own exceptions to a private Discord channel means neither of you needs log access for the common case.
• Document the configuration in the repo. A .env.example listing every variable name — no values — tells your collaborator what the app needs without giving them anything sensitive.
• Keep a staging app the owner also owns, so risky changes get tried somewhere that doesn't page anyone. It costs only the resources it uses.

Plan the handover before you need it#

Single ownership has a failure mode worth naming: the owner loses interest, changes email, or simply stops replying, and the project is stranded on an account nobody else can reach.

The protection is the same discipline that makes deletion survivable:

• Code lives in the repository, which more than one person can access.
• Data is backed up somewhere shared — nothing is backed up for you, and a volume belongs to an app on one account.
• Configuration is written down: variable names, port bindings, volume paths, the run command.

With those three, moving the bot to a different account is a redeploy. Without them, the owner's inbox is a single point of failure for the whole project.

FAQ#

Can I add a teammate to my app?#

No. Applications have a single owner and there's no collaborator or team feature. Share the repository instead and deploy from CI.

How does my collaborator deploy without access?#

Through CI. The owner stores the deploy URL as a repository secret and a workflow pushes on merge, so shipping is merging a pull request.

Can they see the logs?#

Not through the panel. Have the bot report errors to a channel you both see, or paste relevant excerpts into your issue tracker.

Should we just share one account?#

It works, but it means shared credentials nobody can rotate independently. If you do, create an account for the project rather than using a personal one.

What if the owner disappears?#

Recreating the app elsewhere is straightforward if the code is in a shared repo, the data is backed up somewhere shared, and the configuration is documented. Do those now, not later.

Does a second person cost anything?#

There's nothing to pay for — there are no seats. The constraint is access, not price.

Wrapping up#

"One owner per app" reads as a missing feature, and for a team of five it would be. For two people building a bot, it mostly pushes you toward a setup worth having anyway: the repository is the shared artefact, CI does the deploying, and the panel is where one person occasionally goes to change a secret or read a log. Make sure the code, the data, and the configuration all live somewhere more than one of you can reach, and the ownership question stops mattering.