One workspace instead of another integration layer
Macro combines email, channels, documents, tasks, files, calls, customer records, and agents in one application. That sounds like the usual all-in-one sales pitch until you reach its central design choice: every object can link to another object in both directions. A task created from a customer email retains that origin, a document can mention the task, and a pull request can complete the chain. Permissions follow channels, so linked material shared in a channel becomes available to its members.
This shared graph is the reason to consider Macro. Most collaboration suites put products beside one another and add search later. Macro uses the same backend and linking system across purpose-built surfaces. The goal is not merely fewer tabs. It is a record that can answer why work exists and give an agent enough context to act without separately searching email, chat, notes, and a tracker.
The hosted product is the real starting point
Macro's getting-started guide estimates about 15 minutes to connect an account and learn the core workflow. That is credible for a trial. Connect Gmail or Google Workspace, use the unified inbox, create a team and channel, then ask the built-in agent about workspace material. The browser application and an iOS client cover normal use, and keyboard shortcuts are treated as a primary interface rather than decoration.
Mail support is a meaningful boundary. Macro is an email client, not a server, and it currently integrates with Google mail. The documentation calls Outlook and custom IMAP or SMTP support planned. A company standardized on Microsoft 365 cannot evaluate the complete proposition yet. GitHub pull requests integrate with tasks and channels, but GitLab support is still an open feature request. Those are not minor connector gaps when mail and engineering context are central to the product's promised value.
Agents get unusually broad context
Macro refreshes shared team memory from messages, emails, completed work, documents, and calls. That memory is stored as Markdown and can be exported or manually corrected. Agents also receive a tool surface with broad coverage of actions available in the interface, so they can retrieve source objects or create work instead of relying only on a nightly summary. Users can select models from several providers.
The remote MCP server makes the same workspace available to outside clients. The docs provide one command for Claude Code and another for Codex, followed by browser OAuth. MCP access is available on every hosted plan and does not require a local helper process. This is a strong bridge between a team system and coding agents because a task can preserve its related email, discussion, document, and pull request.
Compatibility is still moving. Issue #5519 reports that Macro's protected-resource metadata omitted a required field from RFC 9728, preventing strict MCP clients from completing OAuth discovery. The report identifies the current endpoints and implementation involved, but it remains a reason to test the exact client you intend to deploy. Another planned issue requests credentials or custom headers for connecting MCP servers that do not use OAuth. Macro's own MCP endpoint is useful now; every external MCP arrangement is not automatically covered.
Self-hosting is source access, not an appliance
The repository is genuinely open source under AGPLv3, rather than an open-core shell. That gives operators auditability and the right to run the system, with copyleft obligations for derivative network services. Organizations that need an incompatible closed-source derivative must arrange another license.
Running the full application is substantial. The repository lists 42 deployable services and 167 Rust libraries, alongside a SolidJS client, shared TypeScript packages, Pulumi infrastructure, Docker definitions, and Nix inputs. The preferred development shell supplies Rust, Bun, Zig, cargo-zigbuild, and sqlx. Docker Compose runs local infrastructure, while Doppler normally provides configuration. A local environment file can replace Doppler, but the operator must know what to put in it.
The local command does reduce friction by starting services, the proxy, and front end together. Named instances, health output, cached infrastructure initialization, and headless stack commands show thoughtful internal tooling. There is an explicit rough edge: auxiliary Docker-built services can remain stale unless the stack is started with a rebuild flag. This setup is designed for contributors working in a large monorepo, not casual home-server deployment.
The FAQ is candid that self-hosting was not the primary focus as of June 2026. The hosted system has Apple, Google Mail, and GitHub approvals and uses services including LiveKit, FusionAuth, and PostHog. A self-hoster must maintain licenses for those dependencies or disable them, then own deployment, secrets, storage, email integration, authentication, updates, and recovery. The maintainers hope to improve this area, but that aspiration is not a present installer.
Health and the decision
Development is intense. The repository was pushed on August 11, 2026, one day after release v2026.8.10.0. That release included changes across calendar, email, calls, reminders, GitHub, search, MCP, desktop login, iOS authentication, and infrastructure. GitHub showed 53 open issues and pull requests, while the issue-only search found nine open issues. This is a young public repository with a working product and rapid releases, not a settled platform with slow compatibility cycles.
Macro is most compelling for a small, technical, Google-based company that can actually consolidate its tools. Its common graph gives agents better raw material and gives humans an auditable path from conversation to delivery. Start with hosted Macro and run a real project before considering migration. Choose self-hosting only if your team is prepared to operate the architecture it can see in the source, not because the presence of an AGPL license makes deployment simple.