# Rezee > Specs, issues, code review, CI/CD, error tracking, chat and docs in one workspace. Agents work with the full context, and a person approves what ships. Rezee replaces the usual five-to-seven tool stack - code hosting, issue tracker, CI vendor, chat, and a docs product - with one workspace where those layers share a source of truth. AI agents are members of that workspace rather than an assistant bolted onto it: they read the code, open issues, draft documents and raise pull requests through the same tool surface the team uses, and stop for approval before anything irreversible. ## Pricing - Free forever, every layer, with small monthly pools. - Startup $22 per person per month ($20 billed yearly). - Business $44 per person per month ($40 billed yearly). - One layer from $8: Plan, Code & Ship, or Design & Docs. - Agent accounts are free; their work is metered in credits worth a cent each. - Full table and FAQ: https://rezee.app/pricing ## Product - [Rezee](https://rezee.app/): Specs, issues, code review, CI/CD, error tracking, chat and docs in one workspace. Agents work with the full context, and a person approves what ships. - [Features](https://rezee.app/features): Every Rezee surface, by lifecycle stage: ideate and design, plan and track, code and ship, signals from your own product, discuss and document, and agents across all of them. - [Pricing](https://rezee.app/pricing): Free forever with every layer. Startup $22 and Business $44 per user per month, or one layer from $8. Agent accounts are free; their work is metered in credits. - [Security](https://rezee.app/security): How Rezee protects your work: single sign-on, SCIM provisioning, scoped runner tokens, secrets released at claim time, and an append-only audit log. - [Desktop app](https://rezee.app/desktop): Rezee as a Mac app: a tab for every workspace, restored on launch, with notifications and a Dock badge that keep working when the window is closed. - [MCP server](https://rezee.app/mcp): Connect Claude, ChatGPT, Cursor, Codex or any MCP client to your Rezee workspace: over 290 tools, browser sign-in, and only the permissions you grant. ## Surfaces - [Ideate & Design](https://rezee.app/design): Build specs, boards, reusable components and clickable prototypes in one workspace. Inspect designs, review changes and connect them to code. - [Plan & Track](https://rezee.app/plan): Track issues, projects, cycles and outcomes beside the code. Run playbooks for repeatable work and keep progress linked to what ships. - [Code & Ship](https://rezee.app/code): Review stacked pull requests layer by layer, run CI on pushes, PRs, tags or schedules, and track releases and deployments in one workspace. - [Signals](https://rezee.app/signals): Errors, traces, logs, replays, uptime and metrics from your own product, beside the work that fixes them. Sentry SDKs send to Rezee by changing the DSN. - [Discuss & Document](https://rezee.app/discuss): Keep channels, DMs and docs beside your work. Star rooms, save messages, resume drafts and schedule posts without losing the decision trail. - [AI Agents](https://rezee.app/agents): Give agents focused kits and scoped plugins, follow tasks live, answer their questions and approve irreversible actions before they run. ## Current product capabilities ### Ideate & Design Source: https://rezee.app/design - **Components & prototypes:** Build a component once, give it variants and slots, then place instances across screens. Layout grids keep those screens structured, while prototype links turn the same frames into a flow people can click through. - How it works — Build the source: Publish a frame as a component and define the parts an instance can swap. - How it works — Place it in a screen: Use variants, slots and layout grids to make related screens from the same source. - How it works — Play the flow: Connect frames and open the prototype to test the route through them. - Variants and slots: Instances can change state and content while keeping a link to their source. - Layout grids: Place and align content in a grid, not by guessing coordinates. - Interactive prototypes: Frame-to-frame interactions run from the board and its share link. - **Inspect & design review:** Inspect a finished frame for measurements and styles. Ask an agent to change a board on a branch, review the result beside the original, and see which other boards a shared component change would affect before accepting it. - How it works — Inspect the frame: Turn on Inspect to read spacing and properties without editing the board. - How it works — Request a change: An agent works on a branch and returns a reviewable design request. - How it works — Check the reach: Compare the proposed change and the other boards it would affect before merging. - Redlines: Hover layers to read measurements during handoff. - Code drift: A bound component shows when its source file has moved ahead. - Editable imports: Paste SVG, Mermaid or page content into a board as material you can edit. ### Plan & Track Source: https://rezee.app/plan - **Outcomes:** Track the result a project is meant to produce alongside the work. Outcomes have owners, status and priority, so the team can see what it is aiming for as well as which issues are moving. - How it works — Name the result: Create an outcome for the change the team wants to see. - How it works — Follow its status: Filter planned, active, paused and achieved outcomes in one view. - Status and priority: Keep the outcome's current state visible without reducing it to a ticket count. - A separate Plan view: Read outcomes beside issues, projects and cycles. - **Playbooks:** Create reusable Plan workflows, run them when needed, and read their history. A playbook keeps the sequence visible instead of leaving a recurring process in somebody's memory. - How it works — Create a playbook: Compose a reusable workflow in the workspace. - How it works — Run and review: Start it from the catalog and open the run history to see what happened. - Catalog and history: The definition and its past runs have their own Plan view. - Scoped access: Managing a playbook and running one use separate permissions. ### Code & Ship Source: https://rezee.app/code - **Stacked pull requests:** Split a large change into linked pull requests. Each layer keeps its own diff, discussion, review and checks; the stack shows how the layers fit together and which are ready to land. - How it works — Build the stack: Use the CLI to create and submit related branches and pull requests. - How it works — Review each layer: Move through the stack, inspect a layer's diff or read the whole stack for context. - How it works — Keep it current: Restack after lower layers change, then land a ready prefix in order. - Stack map: See the current layer, adjacent changes, review state and blockers. - Since your review: Read only what changed after your last verdict. - Safe restacking: The CLI can sync and repair local layers; the server tracks published restacks. - **Pipeline triggers & retries:** Pipelines can run on pushes, pull requests, tags or a schedule. Jobs can depend on other jobs, and a failed run can retry the work that failed without starting every step again. - How it works — Declare the trigger: Keep the event and job graph in .rezee/actions.yml with the code. - How it works — Read the run: Open a job to see its steps, logs and failure in context. - How it works — Retry what failed: Run the failed work again without repeating successful work. - More than pushes: Schedules, tags and pull requests can start a run. - Job dependencies: A job waits for the work it declares as a prerequisite. - Targeted retries: Failed work can be retried from the run. - **Release notes:** Ship gathers merged pull requests that have not reached a release yet. Cut a release from that set and start with notes drawn from the changes already recorded in Code. - How it works — Review unreleased work: See merged changes still waiting to go out. - How it works — Cut the release: Group the changes under a version and edit the notes before publishing. - Unreleased changes: Merged pull requests remain visible until a release contains them. - Editable notes: Start with the recorded changes and finish the summary in your own words. ### Discuss & Document Source: https://rezee.app/discuss - **Organized conversations:** Star the channels you return to, group the rest, and resume at the unread line. The rail follows the way a team actually uses chat instead of listing every room in creation order. - How it works — Arrange the rail: Star frequent rooms and group the others. - How it works — Pick up where you left off: Unread markers show where new conversation begins. - Stars and groups: Keep important channels visible without flattening every room into one list. - Unread position: Return to the first message you have not read. - **Drafts, saved & scheduled:** Leave a draft in a channel or thread, save a message to revisit, or schedule one to send later. Each has a place to find it again. - How it works — Start now, finish later: A draft stays attached to the conversation where you began it. - How it works — Save or schedule: Bookmark a message for yourself or choose when a new one should be sent. - Drafts: Unsent channel and thread messages appear together. - Saved messages: Open the original conversation from your saved list. - Scheduled messages: See pending messages before they go out. ### AI Agents Source: https://rezee.app/agents - **Agent kits & plugins:** An agent can carry a focused kit instead of every tool in the workspace. Plugins declare the access they need, and a workspace grants it by name before they can reach anything outside their container. - How it works — Pick a kit: Assign a tool set that fits the agent's work. - How it works — Review plugin access: Grant only the connections and permissions the plugin asks for. - Focused tools: Each task starts with the tools relevant to its kit. - Isolated plugins: Plugins run inside a container until explicit access is granted. - Reviewable identity: Agent configuration lives with the agent's activity and usage. - **Interactive task control:** Watch an agent's steps as they happen. It can ask for clarification rather than guess; you can answer, correct the task, stop it, and see its usage from the task page. - How it works — Delegate a task: Assign work or start it from a watch or schedule. - How it works — Follow the run: Messages, tool calls and results arrive on the task page as they happen. - How it works — Steer it: Answer a question, give a correction or stop the run. - Clarification: An agent can pause to ask instead of inventing an answer. - Live steps: The task page shows progress while the agent works. - Usage visibility: See the cost of a task with the work it produced. ### Signals Source: https://rezee.app/signals - **Errors, grouped:** Events are grouped by their stack's fingerprint. Resolve one in its current release and later events from that same build do not reopen it; an event from any other release reopens it, marked as regressed. - How it works — Grouped on arrival: The ingest service fingerprints each event's in-app frames, so a thousand of the same crash are one row with a count. - How it works — Resolve in a release: Late events from that same build do not reopen it. - Merge and split: Two groups that are one problem merge; a fingerprint that is not splits back out. - Scrubbed before it is kept: Emails, card numbers, tokens and secrets are filtered at ingest. - **Switch from Sentry by changing the DSN:** The ingest endpoints speak Sentry's envelope and store formats, so an app already instrumented with a Sentry SDK sends to Rezee once its DSN is the one from Settings → Signals. - How it works — Copy the DSN: Each source has keys; a browser key can be held to your site's origins. - How it works — Or use Rezee's SDKs: @rezee/browser and @rezee/node report errors from one init call; traces and logs are a call more. - OTLP too: Traces, logs and metrics from OpenTelemetry go to the same source over OTLP/HTTP. - Rate per key: Each key has its own rate, and what it refused is counted on the source. - **Source maps & suspect commit:** Upload a release's source maps with the CLI and minified frames read as your source. The deploy before an error first appeared, and the commits in it that touched its stack, are named on the error. - How it works — Upload with the release: rezee sourcemaps upload, or sentry-cli pointed at Rezee. - How it works — Suspect from the code: Commits are matched to the files in the error's stack, not guessed by time alone. - Repository per source: A source names the repository its code lives in. - **Traces & slow releases:** Page loads and requests are traced, with web vitals for pages. Each endpoint's p95 is compared release to release, and a slower one becomes a finding with its before and after. - How it works — Sampled, joined: A traced page passes its trace to requests on its own origin, and @rezee/node's traceRequest continues it, so one trace covers both sides. - How it works — Findings per release: Read per source, service and environment, in the order releases first shipped. - Errors in their trace: An error raised inside a traced request opens to that trace. - **Logs:** Logs from the SDKs, Sentry and OTLP are searched by text, level, source and environment, or tailed as they arrive. A trace shows the lines logged inside it. - How it works — Saved searches: A search worth keeping is saved, and can be the target of an alert. - A team of its own: Logs can be limited to a named team. - **Session replays:** A share of sessions is recorded, and every other one keeps the minute before an error or a feedback report. Every piece of text and every input is masked in the browser; a page marks what may show, and password, one-time-code and card fields never do. - How it works — Linked both ways: An error lists the replays of the sessions it happened in, and a report links the replay of what led to it. - How it works — Friction per page: Rage clicks, dead clicks and, in a single-page app, going straight back are counted per page, each with a replay to watch. - Loaded only when on: The recorder is its own file, fetched only on pages that turn replays on. - A team of its own: Replays can be limited to a named team. - **Uptime & status page:** Monitors check a URL every 1, 5 or 15 minutes for a status and the text it should carry. Two failures in a row open an incident; the first success resolves it. A public status page shows the last 90 days. - How it works — Checked from one region: Each check connects to the address it resolved and checked, so it cannot be turned toward a private one. - Certificates: A certificate close to expiry is flagged on its monitor. - **Metrics & dashboards:** OTLP metrics and the ones Rezee derives - requests, p95, error rate - are charted on dashboards, grouped by an attribute, and embedded in docs. - How it works — Raw or rolled up: Recent windows read raw points; longer ones read an hourly rollup. - In a doc: A chart is a block in a doc, kept current. - **Alerts:** Rules on a metric, a saved log search or an error fire once when they start to hold and resolve themselves when they stop, posting to a channel and opening an incident when asked. - How it works — Quiet hours respected: An alert reaches people within the notification settings they chose. - On a track: Each rule names the engineering or product track it belongs to. - **Engineering & product tracks:** Errors, slow releases and failing monitors go to the engineering track; a feedback theme follows what its feedback asks for, and a model places the mixed ones with a line why. Errors and accepted causes are filed in the engineering team's Intake, feedback themes and write-up specs in the product team's, and people move anything. - How it works — Moves stand: A person's move is never undone by the rule, and repeated moves show to admins. - Team per source: A source can name its own engineering and product teams. - **One problem, one item:** An error, a slow route, a failing monitor and a feedback theme about the same problem are joined when they share customers, a page, a session or their words - with both counts and both sets of customers on the item. Weaker matches are offered; anything can be separated. - How it works — Sessions count: Feedback sent from a browser session that hit the error is the strongest link. - Separated for good: A pair a person separates is never joined again by a match. - **Likely cause & draft fix:** An error's diagnosis reads its stack, the suspect commit, its trace and the logs around it, then deploys, changes and tests. At high confidence the fix agent drafts a pull request; once the fix ships, the error and its routes are watched for 14 days and reopened if they come back. - How it works — Confirmed into Intake: Accepting the cause files the fix for the engineering team, with the evidence as the issue's body. - Old builds do not count: Only a build newer than the fix raising the error reopens it. - **Problem write-ups:** A product theme is written up from its feedback, its counts and the code a change would touch: the problem in customers' words, who has it, the need beneath it, options with how each would be built, and a recommendation. Accepting it with an option drafts the spec. - How it works — Cited, or refused: A write-up whose claims cite nothing is not kept. - In place of the insight: On the product track, the write-up is what the theme shows. - **Quotas with a hard cap:** Each plan includes a monthly number of errors and an amount of spans and logs, and caps how many monitors and dashboards you keep. At the limit, ingest keeps one in ten for a little while, then stops, and owners are told. Packs raise the limit; nothing is charged past what you buy. - How it works — Usage by source: Billing shows each meter by source, with where the month is heading. - SDKs back off: Sentry's SDKs and OpenTelemetry exporters are answered so they stop resending. - **Retention & scrub rules:** Set how long errors, traces and logs are kept, up to your plan's ceiling; shortening removes what is older. Add your own scrub rules - a field always filtered, or a pattern - on top of the built-in ones, and try them on sample text first. - How it works — Audited: Every change to retention, rules or who reads logs is in the audit log. - Patterns that cannot stall: Rules are a small pattern language rather than regular expressions, so one cannot slow ingest. ## Documentation - [Documentation](https://rezee.app/docs): Get started with Rezee: a five-minute quickstart, the rezee command line reference, and the REST API for building on top of your workspace. - [Quickstart](https://rezee.app/docs/quickstart): Create a workspace, push your first repository, open a pull request and watch a pipeline run - the whole loop, in about five minutes. - [Workspaces & roles](https://rezee.app/docs/workspaces): What a workspace holds, what member, admin and owner each unlock, the roles a workspace can write for itself, and the settings a repository keeps back. - [Git access](https://rezee.app/docs/git): Where repositories live, how HTTPS and SSH authenticate, who may read and who may push, and what a push sets off - pipelines, webhooks, and issue links. - [Repositories](https://rezee.app/docs/repositories): Repository settings in Rezee: collaborators, branch protection rules and how overlapping ones combine, releases beside their tags, and archiving. - [Pipelines](https://rezee.app/docs/pipelines): Rezee CI: .rezee/actions.yml, cached toolchains, encrypted secrets, artifacts and streamed logs. Push a commit and the run starts. - [Search](https://rezee.app/docs/search): Search issues, documents, chat, pull requests, code paths and agent tasks in one query: what is indexed, the syntax, and what a scoped token sees. - [CLI reference](https://rezee.app/docs/cli): All 27 rezee commands: issues, pull requests, pipelines, agents, chat, releases and workspace administration - without leaving your shell. - [API reference](https://rezee.app/docs/api): The Rezee REST API: authentication, scoped tokens, rate limits, and the endpoints behind every surface in the product. - [actions.yml reference](https://rezee.app/docs/actions): Every key .rezee/actions.yml accepts: on.push filters and their glob syntax, jobs, images, cached toolchains, steps and artifacts, with their defaults. - [Tokens & capabilities](https://rezee.app/docs/tokens): Minting personal access tokens, the capabilities they carry, ws: and repo: scopes, and the surfaces no scoped token can reach whatever it holds. - [Webhooks](https://rezee.app/docs/webhooks): Deliver push, issue and pull request events to your own URL: the payloads, the headers, how to verify the HMAC signature, and what delivery does not promise. - [Runners & CI minutes](https://rezee.app/docs/runners): Where pipelines run, dedicated runners and why they are owner-only, minutes counted per job and rounded up, the pools per plan, and what happens at the limit. - [SSO, domains & SCIM](https://rezee.app/docs/sso): Connect an OIDC or SAML identity provider, claim your domain so people sign in with their work email, and let a SCIM 2.0 directory manage membership. - [Audit log](https://rezee.app/docs/audit): Around forty recorded verbs across access, secrets, protection, agents and identity, plus every successful agent write - and how long each is kept. - [Agents](https://rezee.app/docs/agents): How agents work in Rezee: what a token carries, the seven ways work reaches one, the task lifecycle, and the gate in front of the irreversible. - [MCP](https://rezee.app/docs/mcp): Rezee is an MCP server: 270+ tools for code, issues, pull requests, docs, design, chat and CI. Connect with the CLI, or with OAuth and nothing pasted anywhere. - [Signals](https://rezee.app/docs/signals): Make a source, put its DSN in your app, and the next error it throws is grouped in Signals, with its stack, its release and the commit likely behind it. - [Switching from Sentry](https://rezee.app/docs/sentry): Rezee's ingest speaks the protocol Sentry's SDKs send: point yours at a Rezee DSN and its errors, transactions and logs arrive in Signals. - [OTLP](https://rezee.app/docs/otlp): Send OpenTelemetry traces, logs and metrics to a Rezee source over OTLP/HTTP, as protobuf or JSON, with the source's key as a bearer token. - [Source maps](https://rezee.app/docs/sourcemaps): Upload a release's source maps with the Rezee CLI or sentry-cli, and a minified stack reads as your source, with the commit that changed its lines. - [Signal quotas, retention and scrubbing](https://rezee.app/docs/signal-quotas): What each plan includes per month, what happens at the cap, how long each kind of signal is kept, and the rules that filter data before it is stored. ## Comparisons - [Rezee vs Canny and Productboard - where should customer feedback live?](https://rezee.app/blog/rezee-vs-canny-and-productboard): Canny and Productboard are good at hearing customers. The issue, the code and the release that answer them live somewhere else. An honest comparison with Rezee's model, where feedback sits in the same workspace as the work. - [Rezee vs GitHub, PagerDuty and LinearB - deploys, incidents and delivery metrics in one place](https://rezee.app/blog/rezee-vs-github-pagerduty-and-linearb): Many teams track deployments in GitHub, run incidents in PagerDuty and read delivery metrics in LinearB. An honest comparison with Rezee, where the deployment, the incident and the number are rows in one database - and a plain list of what each of those three tools does better. - [Rezee vs Figma + Linear - where should design-to-ship actually live?](https://rezee.app/blog/rezee-vs-figma-and-linear): Figma is where the design is, Linear is where the work is, and the handoff between them is a link somebody pasted. An honest comparison with Rezee's model, where the board, the spec, the issues and the agent that drew them share one workspace. - [Rezee vs Notion + Slack - where should an engineering team's knowledge and conversation live?](https://rezee.app/blog/rezee-vs-notion-and-slack): Notion holds the docs, Slack holds the conversation, and neither knows what the code is doing. An honest comparison with Rezee's model, where docs and chat share a workspace with the work itself. - [Rezee vs Linear + GitHub - do planning and code belong in separate tools?](https://rezee.app/blog/rezee-vs-linear-and-github): Linear plus GitHub is the modern startup default - a great planner synced to a great code host. An honest look at what that pairing does well, where the sync model leaks, and when one workspace is the better answer. - [The best all-in-one developer platforms in 2026](https://rezee.app/blog/best-all-in-one-developer-platforms): A fair guide to the platforms that unify code, planning, CI/CD, and more - GitLab, Atlassian, Gitea and Forgejo, OneDev, and Rezee - with honest strengths, gaps, and who each one actually fits. - [Rezee vs GitHub - when a unified workspace beats a code-first platform](https://rezee.app/blog/rezee-vs-github): GitHub is the default home for code. Rezee is a workspace for the whole lifecycle - code, planning, CI/CD, chat, and docs. An honest comparison for teams deciding where their work should live. - [What your team actually pays for GitHub + Linear + Slack + Notion + CI](https://rezee.app/blog/what-your-dev-stack-actually-costs): The real monthly cost of the standard startup dev stack - subscription math for a 10-person team, plus the hidden costs of seams - and an honest look at when consolidation pays. - [Rezee vs the Atlassian stack - Jira, Bitbucket, and Confluence, or one workspace?](https://rezee.app/blog/rezee-vs-atlassian): Atlassian assembled the enterprise standard - Jira for planning, Bitbucket for code, Confluence for docs. An honest comparison with Rezee's single-workspace model, and who each is really for. - [The best tools for teams working with AI coding agents in 2026](https://rezee.app/blog/best-tools-for-ai-agent-teams): A practical guide to the agent-era stack - coding agents, review tooling, CI, and the workspace layer that gives agents context and guardrails - with honest notes on what each piece solves. - [Rezee vs GitLab - two takes on all-in-one](https://rezee.app/blog/rezee-vs-gitlab): GitLab unified the DevOps toolchain. Rezee unifies the product development lifecycle - including chat, docs, and AI agents. An honest comparison of scope, strengths, pricing, and when to pick each. ## Guides - [Connect any AI tool to your workspace over MCP](https://rezee.app/blog/connect-ai-tools-over-mcp): A practical guide to the Model Context Protocol - what a server and a client are, a remote URL with OAuth versus a local stdio process, how consent and scopes should work, why a client should confirm before it writes, and how Rezee does each of these. - [Code ownership without slow reviews - how to design CODEOWNERS so review stays fast](https://rezee.app/blog/code-ownership-without-slow-reviews): A CODEOWNERS file can protect the code that matters or make every pull request wait on the same two people. How to design ownership around risk, teams and fewer approvals for low-risk work, and how Rezee enforces it. - [Running an incident - from the first chat message to a postmortem that files work](https://rezee.app/blog/running-an-incident-to-a-postmortem): A practical way to run an incident on a small team, from the moment someone says "is anything broken?" to a postmortem whose follow-ups are tracked issues. Declare early, keep an append-only timeline, ask what changed first, and end with work rather than a document. - [Design reviews that end in issues, not opinions](https://rezee.app/blog/design-reviews-that-end-in-issues): Why most design reviews produce a pile of comments and no work - and a practical structure for running one that ends with tracked issues, a named decision, and a record you can read six months later. - [The product development lifecycle in one place - a practical guide](https://rezee.app/blog/product-development-lifecycle-guide): A walkthrough of the full lifecycle - idea, spec, plan, build, review, ship, learn - with the handoffs where teams lose context, and how to run each stage so the next one inherits everything. - [How to onboard an AI agent as a teammate (and keep the final say)](https://rezee.app/blog/onboarding-ai-agents): A practical playbook for adding an AI agent to a software team - choosing first tasks, scoping permissions, setting review gates, and growing trust in stages without losing human control. - [Docs that don't rot - keeping engineering knowledge next to the code](https://rezee.app/blog/docs-that-dont-rot): Why engineering documentation decays, which docs are worth writing at all, and the structural habits - ownership, proximity, and living status - that keep knowledge truthful. - [What context switching actually costs your engineering team](https://rezee.app/blog/cost-of-context-switching): The research on interruption and attention residue, translated into engineering terms - what tab-hopping between code, tracker, chat, and docs really costs, and what actually reduces it. - [How small teams should structure issues, labels, and workflows](https://rezee.app/blog/issue-tracking-for-small-teams): A minimal issue-tracking setup that stays truthful - what states you actually need, which labels earn their keep, how big an issue should be, and the habits that prevent tracker rot. - [Code review best practices - reviews that don't slow the team down](https://rezee.app/blog/code-review-best-practices): How to keep code review fast and useful at the same time - small PRs, clear review levels, latency norms, and what reviewers should actually look for (and skip). - [Spec to issues to shipped - how to keep planning and code in sync](https://rezee.app/blog/spec-to-shipped): Why trackers drift from reality, how to link issues to pull requests so status maintains itself, and the closed-loop workflow that keeps a spec truthful from first draft to deploy. - [A beginner's guide to CI/CD pipelines in YAML](https://rezee.app/blog/ci-cd-pipelines-yaml-guide): What CI/CD actually does, how to read and write pipeline YAML - jobs, steps, dependencies, artifacts, secrets - and the habits that keep pipelines fast and trustworthy. - [How to write an RFC that actually gets read (with template)](https://rezee.app/blog/how-to-write-an-rfc): A practical guide to writing engineering RFCs - what to include, what to cut, how to route them for review, and a copy-paste template your team can adopt today. ## Engineering - [Hardening the git server - deadlines, early conflicts, and push work that survives a restart](https://rezee.app/blog/hardening-the-git-server): Five changes to denji and makima. Every git call now has a deadline and an output cap, a pull request learns it conflicts when a branch moves, a review survives a comment-only push, a push's follow-up work lives in Postgres until it is done, and clients get protocol v2 without Rezee's private refs. - [Catching flaky tests from results - and quarantine with an owner and an expiry](https://rezee.app/blog/flaky-tests-and-quarantine): Rezee parses a job's JUnit reports into test results, counts a flake when one commit sees a test both pass and fail, and lets a team quarantine a flaky test only with an owner and an expiry. The exact rule, the lock that keeps it correct, and the runner change quarantine needed. - [Mirroring OSV hourly - and naming which live build carries each advisory](https://rezee.app/blog/mirroring-osv-live-advisories): Rezee reads lockfiles on every branch push, mirrors OSV's advisories for five ecosystems every hour, and joins both to Ship's deployments, so a finding names the environments that run it. How the mirror stays incremental, how a version is matched, and how a fix becomes a pull request. - [API contract diffs on every push - reading OpenAPI, GraphQL and protobuf against the fork point](https://rezee.app/blog/api-contract-diffs-on-every-push): Rezee reads a repository's API contracts on every branch push, keyed by blob sha, and diffs a pull request's contract against the commit it forked from. The rules that call a change breaking, why the base branch's tip was the wrong "before", and why accepting a break is bound to one commit. - [A restack is a state machine, not a script - publishing a rebased stack without losing a branch](https://rezee.app/blog/restack-as-a-state-machine): Rezee rebases a stack of pull requests behind private refs and publishes it in one leased transaction. The five durable phases, the crash window each one closes, and why a stale-ref error is sometimes a receipt. - [One store, several writers - replacing a cache of REST answers with a pool of rows](https://rezee.app/blog/one-store-several-writers): The board stopped being a function of the last query the server ran. How Rezee's client keeps canonical rows in memory, mirrors them to IndexedDB, and why a complete slice is smaller on the wire than the single page it replaced. - [Production latency was round trips, not queries - what 2.4 seconds of cold launch was actually made of](https://rezee.app/blog/latency-is-round-trips): Every query returned in 1 to 5 milliseconds and the box was idle. The slow endpoints were serial awaits, and the worst one was justified by a code comment that was confidently wrong. - [One renderer, four readers - the scene format behind Rezee's canvas](https://rezee.app/blog/one-renderer-four-readers): A design canvas whose documents are a typed scene graph rather than pixels - why the write model is a CRDT of named nodes, why scene to SVG is a pure function with exactly one implementation, and what that buys an agent that draws. - [Highlighting a 5,000-line diff without freezing the tab](https://rezee.app/blog/async-shiki-diff-tokenization): How Rezee's diff viewer syntax-highlights large diffs without a frozen frame - Shiki tokenization is synchronous CPU, so the trick isn't going off-thread, it's chopping one 305ms block into 125 sub-5ms bursts, measured. - [Drag a card, write one row - fractional indexing on the issues board](https://rezee.app/blog/fractional-indexing-drag-reorder): How Rezee persists Linear-style drag reordering - the lexicographic midpoint algorithm behind issues.rank, measured key growth under adversarial dragging, why float ranks die at exactly 53 moves, and a 5,000x difference in rows written. - [A service mesh in one HTTP header - and the measured case against mTLS](https://rezee.app/blog/one-header-service-mesh): How Rezee secures service-to-service calls with a shared-secret header instead of mutual TLS - the threat model each covers, a measured 1.2ms mTLS handshake that keep-alive erases, and why the real decision is operational, not performance. - [The workspace is the context window - why agents work better unified](https://rezee.app/blog/workspace-as-context-window): The engineering thesis behind Rezee's agent bet - an agent in a unified workspace gets context, permissions, identity, and a safety gate as properties of one system, each measured in a sibling post, where a stitched stack rebuilds all four per integration. - [One search across five surfaces - on Postgres, and when it falls over](https://rezee.app/blog/unified-search-postgres-fts): How Rezee searches issues, docs, chat, PRs, and code paths with Postgres full-text search instead of a separate engine - measured GIN latency to 1,000,000 rows, the p99 tail that is the real fall-over signal, and why workspace-scoping keeps it flat. - [A ref named --output - defending a shell-out git API from option injection](https://rezee.app/blog/git-api-option-injection): How Rezee's git read layer stops a repository ref from becoming a git flag - the real arbitrary-file-write exploit, the two guards in denji's gitdata.go, a four-config attack matrix showing what each layer independently catches, and the one command where --end-of-options provides zero protection. - [A git SSH server in 300 lines, with the key database in another service](https://rezee.app/blog/git-ssh-server-delegated-auth): How Rezee serves git over SSH with delegated public-key auth - denji holds no keys, resolves fingerprints through makima, and runs stateful upload-pack (no --stateless-rpc) - plus the measured ref-advertisement cost that separates SSH from HTTP transport. - [Closes ACME-12 - parsing closing keywords without closing the wrong issue](https://rezee.app/blog/issue-pr-autoclose-parsing): How Rezee links a merged PR to the issue it closes by parsing closing keywords - tested against 500 real OSS pull requests, where the naive regex would have auto-closed the wrong issue from a code block, and the two corrections that stop it. - [Killing the 2-second poll - one SSE stream for the whole workspace](https://rezee.app/blog/sse-vs-polling): The engineering behind Rezee's real-time sync engine - measured costs of polling vs server-sent events (requests, wire bytes, staleness), the anatomy of an SSE stream, the proxy and connection-limit traps, and why writes stay REST. - [Scoped tokens - giving an agent the minimum, and proving it holds](https://rezee.app/blog/scoped-tokens-for-agents): How Rezee scopes agent access tokens to capability and resource - the scope grammar, the single matcher that gates every tool call, and a 200,000-pair adversarial fuzz proving zero privilege escalations against an independent oracle. - [One tool surface for humans, agents, and MCP - generated, not maintained](https://rezee.app/blog/one-tool-surface-mcp): How Rezee exposes the same API to its UI, external agents over MCP, and first-party agents - 65 MCP tools mechanically derived from the same TypeBox route schemas, so the tool an agent calls and the endpoint a human hits are the same code. - [The life of a CI log line (or - how "live" do live logs need to be?)](https://rezee.app/blog/life-of-a-ci-log-line): How a log line travels from a build container to your browser in Rezee - scanner, redaction, 20-line batches, one Postgres row per line, and 2-second polling - and why we chose boring over push. - [How encrypted secrets work in Rezee pipelines](https://rezee.app/blog/how-pipeline-secrets-work): The full path of a CI secret - AES-256-GCM at rest, names-only listing, decryption only at dispatch over an internal channel, Docker env injection that stays out of inspect, and log redaction with honest caveats. - [How we built a CI runner in Go (in about 500 lines)](https://rezee.app/blog/building-a-ci-runner-in-go): The architecture of kobeni, Rezee's pipeline executor - Postgres as the job queue, optimistic claims, a throwaway Docker container per step, zipped artifacts, and the gaps we haven't filled yet. - [The post-receive hook is the event bus - one git push, measured end to end](https://rezee.app/blog/post-receive-event-bus): How a git push in Rezee triggers pipelines and signed webhooks across two services with no message broker - the env-injected shell hook, fire-and-forget at every hop, and a measured 75-second push stall that the design's own honesty exposed. - [Keep the LLM loop out of the API - the beam agent runtime](https://rezee.app/blog/beam-agent-runtime): Why Rezee runs agents in a separate worker service instead of inside the API - a measured 14x tail-latency blowup when the agent loop shares the request path, and the kobeni-shaped runtime that avoids it. - [The approval gate - how "humans keep the final say" works as a state machine](https://rezee.app/blog/agent-approval-gate): The engineering behind Rezee's agent approval gate - the agent_tasks state machine, why steps are append-only rows, the conditional UPDATE that makes double-approval impossible, and what happens when the runtime dies mid-task. - [Designing workspace-scoped multi-tenancy for a developer platform](https://rezee.app/blog/workspace-scoped-multi-tenancy): How Rezee isolates workspaces on one Postgres - scoping by foreign key, revocable server-side sessions, hashed access tokens, and the single authorize endpoint that answers every git permission question. - [Our job queue is one Postgres UPDATE - so we raced it until it broke](https://rezee.app/blog/postgres-job-queue-one-update): We benchmarked the atomic claim behind Rezee's CI queue against the naive version and FOR UPDATE SKIP LOCKED - 100 concurrent workers, 10,000 jobs, real numbers on duplicates, wasted claims, latency, and the surprising way a guarded queue slows down under contention. - [Agents are just users - the one schema decision that made every surface agent-ready](https://rezee.app/blog/agents-are-just-users): How Rezee made AI agents first-class teammates with a single enum column - 15 existing foreign keys that worked on day one, the two columns that fought back, and the measured cost of the polymorphic alternative we didn't pick. - [Why Rezee runs on Go, Bun, and React](https://rezee.app/blog/why-go-bun-and-react): The reasoning behind Rezee's polyglot stack - Go for the git engine and CI executor, Bun and ElysiaJS for the API, React with TanStack for the UI - and the seams between them. - [How we built a git server in Go (without reimplementing git)](https://rezee.app/blog/building-a-git-server-in-go): The architecture of denji, the git engine behind Rezee - smart HTTP and SSH transports in ~2,000 lines of Go, one dependency, and the git binary doing what it does best. ## Notes from the team - [Agents that interrupt less - how Rezee's agents ask, act and step back](https://rezee.app/blog/agents-that-interrupt-less): A note from the team on the work behind DOC-64. Agent suggestions that say why, writes you can undo, corrections that stick, leave to act that is earned per tool, and a daily budget for how often an agent may interrupt you. - [From customer feedback to a shipped reply - closing the loop in one workspace](https://rezee.app/blog/customer-feedback-to-shipped-reply): Customer feedback in Rezee lands in the same workspace as the issues, code and releases that answer it. How a sentence from a customer becomes a theme, an issue with demand on it, and one email when the work ships. - [Agents live in chat - the thread is the task](https://rezee.app/blog/agents-live-in-chat): Message an agent in a DM, or name it in a channel, and that thread becomes the task. The agent's work, its state and the decision on anything it cannot undo all sit under the message that asked for it. - [Two-factor sign-in, and workspaces that require it](https://rezee.app/blog/two-factor-sign-in): Rezee accounts can now ask for a code from an authenticator app after the password, with ten recovery codes. An owner or admin can require it of every member, and a member without one is shown how to fix it instead of a wall of errors. - [Cycles that forecast - capacity you can check, and the views you read the plan through](https://rezee.app/blog/cycles-that-forecast): Rezee cycles now have issue sizes, a capacity target, a forecast built from the cycles you already finished, and a record of every scope change. Saved views and project labels are how you read the plan. - [What is live where - Ship as the record of every deploy, not the thing that runs it](https://rezee.app/blog/ship-the-record-of-what-is-live-where): Rezee's Ship layer records deployments instead of performing them. Environments, three ways to report a deploy, a grid of what runs where, rollback and promote as plain verbs, release trains that never execute anything, and four delivery numbers you can open. - [A design system your boards are actually held to](https://rezee.app/blog/design-system-a-board-is-held-to): Most design systems are a document everyone agrees with and nobody is stopped by. Rezee's is a document a board names, enforced on the write - with an escape hatch, an exact-match rewrite, and a refusal that tells you the nearest token. - [Inside Rezee - agents as teammates, not features (AI & Agents)](https://rezee.app/blog/inside-rezee-ai-and-agents): The thinking behind Rezee's AI & Agents layer - agents as workspace members with scoped access and full attribution, working assigned issues, CI failures, review, and doc drafts, with humans holding the gates. - [Inside Rezee - from push to production in one layer (Code & Ship)](https://rezee.app/blog/inside-rezee-code-and-ship): The thinking behind Rezee's Code & Ship layer - standard git over HTTPS and SSH, inline pull request review, protected branches, and YAML pipelines with isolated steps and live logs. - [Inside Rezee - chat that knows what you're talking about (Discuss & Document)](https://rezee.app/blog/inside-rezee-discuss-and-document): The thinking behind Rezee's Discuss & Document layer - channels and threads beside the work, PR and issue unfurls that stay live, and one search across chat, docs, code, and issues. - [Inside Rezee - why specs live next to the code (Ideate & Design)](https://rezee.app/blog/inside-rezee-ideate-and-design): The thinking behind Rezee's Ideate & Design layer - a block editor with live presence, RFC templates and numbering, live references, and specs that live next to the code they describe. - [Inside Rezee - planning that closes itself (Plan & Track)](https://rezee.app/blog/inside-rezee-plan-and-track): The thinking behind Rezee's Plan & Track layer - issues with owners and workflows, projects and milestones, and pull requests that close issues automatically so the tracker stays truthful. - [Rezee for agencies - a clean workspace per client, a clean handoff at the end](https://rezee.app/blog/rezee-for-agencies): How development agencies run client work in Rezee - isolation between clients, the whole delivery record in one place, and handoffs where the client gets everything, not a zip file. - [Rezee for agent-forward teams - the workspace built for humans plus agents](https://rezee.app/blog/rezee-for-agent-forward-teams): How teams that develop with AI agents from day one run on Rezee - one permission model, full context for delegation, review as the human bottleneck solved structurally. - [Rezee for solo founders - a whole team's tooling for a team of one](https://rezee.app/blog/rezee-for-solo-founders): How a solo technical founder runs specs, planning, code, CI, and AI agents in one workspace - why tool sprawl hurts most at n=1, and how agents become your first teammates. - [Rezee for 5-person startups - one workspace before the seams set in](https://rezee.app/blog/rezee-for-small-startups): How a small startup team runs its whole lifecycle in Rezee - the moment tool sprawl starts costing real money, the consolidation math, and onboarding a team without an onboarding doc. - [How we use Rezee to build Rezee](https://rezee.app/blog/how-we-use-rezee-to-build-rezee): Dogfooding all the way down - how the Rezee team runs specs, planning, code, CI, and agents inside Rezee itself, what the naming scheme is about, and what building on your own product teaches you. - [Why we built Rezee - the case against seven SaaS tabs](https://rezee.app/blog/why-we-built-rezee): Product development is scattered across code hosting, issue tracking, CI, chat, and docs that never quite agree. Rezee is our answer - one workspace for the whole lifecycle, built for teams and their AI agents. - [Introducing the Rezee blog](https://rezee.app/blog/introducing-the-rezee-blog): What we'll write about here - practical guides on shipping software, engineering deep-dives on how Rezee is built, honest tool comparisons, and notes on the product itself. ## Legal - [Privacy Policy](https://rezee.app/privacy): What Rezee collects, why we are allowed to, who else can see it, how long we keep it, and how to get your data out or get rid of it. - [Terms of Service](https://rezee.app/terms): The agreement between your team and ours: accounts, your content, acceptable use, plans and payment, uptime, leaving, and liability. - [Data Processing Addendum](https://rezee.app/dpa): How Rezee processes personal data on your instructions: security measures, subprocessors, breach notice within 72 hours, deletion, and the SCC annexes. - [Subprocessors](https://rezee.app/subprocessors): Every company outside Rezee that can reach your data, what it does for us, what it can actually see, and where. Plus what is deliberately absent. ## Optional - [Changelog](https://rezee.app/changelog): Every release, in order, with what changed and why. Follow along as Rezee ships across code, planning, CI/CD, documents and agents. - [Status](https://rezee.app/status): Live health of Rezee's API, git, app and CI, with 90-day uptime from the deployment itself. - [Blog index](https://rezee.app/blog): Education, engineering deep-dives, honest comparisons, and product notes from the team building Rezee - the unified workspace for everything your team ships. - [RSS feed](https://rezee.app/rss.xml): every post, newest first.