Different ways to work. One little green box.
Your project.
Your kind of work.
Two developers or a whole software factory. Keep the work together, and choose where it lives.
Find your scenario ↓
01 / Private projects
Just two developers. And the work.
A side project, a quiet experiment, or something you are not ready to announce. Keep issues, decisions, and code together without setting up a public project or a Hubnot service.
Put it to work
Work in your local repositories and exchange selected collaboration through a private, compatible Git remote. You choose who gets access.
Start a private project ↗Privacy follows your machines, remote permissions, and secure transport. Hubnot signatures establish attribution; they do not encrypt the project.
02 / Self-hosted Git
Your server. Your project.
Already have a place for your Git repositories? Bring collaboration home with them. Give your team issues, projects, and discussions without adding a central Hubnot application server.
Put it to work
Use a compatible remote that can transport Hubnot’s custom refs. Keep the repository and its collaboration on infrastructure you operate.
Check your Git host ↗Check custom-ref support and backup coverage for your particular host; ordinary source-code hosting alone does not establish compatibility.
03 / Cloud migration
Leave the platform. Keep the context.
Changing providers should not mean abandoning the story of your work. Bring supported project content into a portable repository or archive, then choose what happens next.
Put it to work
Plan and inspect a migration from GitHub, GitLab, Forgejo / Codeberg, Gitea, Bitbucket Cloud, or Azure DevOps. Review mappings before applying changes.
Plan a migration ↗Provider coverage varies. Bitbucket Cloud is source-only, and an archived record cannot always be recreated at another provider.
04 / Multiple platforms
More than one home for your work.
Keep a local working copy, use infrastructure you trust, and work with hosted services where they help. Your collaboration does not have to depend on a single destination.
Put it to work
Synchronize selected native collaboration through compatible Git remotes. Use provider adapters separately when you need to transfer supported platform records.
Understand synchronization ↗Native ref transport and provider migration are different paths. This is explicit synchronization, not automatic, bidirectional mirroring of every service.
05 / Agents & software factories
Give the next agent a head start.
A fresh session should not mean rediscovering every decision. Keep deliberate project memory beside the code, and let your own CI workers produce evidence for the work.
Put it to work
Record decisions and handoffs against commits. Request checks, run authorized pipelines on your workers, and use signed results with review and governance policy.
Explore agent memory ↗Hubnot supplies collaboration, memory, and CI building blocks. Your orchestration controls the agents; your release tooling handles deployment.
06 / Distributed teams
Different time zones. Shared context.
Keep the decisions with the work so the next teammate can pick up where you left off. Issues, discussions, and project history travel with your collaboration.
Put it to work
Work locally, synchronize selected facts when connected, and leave explicit handoffs and review evidence for teammates to inspect.
Bring the discussion along ↗Synchronization and trust decisions are explicit. Shared history does not promise instant updates or automatically resolve every disagreement.
07 / Continuity & handoffs
Make the project outlast the platform.
People move on. Providers change. A project should still make sense to whoever inherits it. Preserve more than a source-code snapshot when you archive or hand over the work.
Put it to work
Create a portable archive of selected Git history, collaboration facts, and retrieved source records. Inspect what it contains before handing it on.
Explore portable archives ↗Archives contain what you select and retrieve. Verify coverage and keep appropriate backups; they are not a promise of complete platform reproduction.
Start small. Keep your options.
What are you building?
Start with a repository. Bring the rest of your project along.