Doory vs Penpot: Choosing a Self-Hosted Design Tool for Marketing Assets

If your team produces marketing assets on infrastructure you control, the decision between Doory and Penpot is not really a comparison of two editors. It is a routing decision. Doory’s README describes a browser-based editor for posters, social posts, stories, slides, invitations, thumbnails and business cards, deployed as a single Docker Compose stack. Penpot describes itself as “the open-source design platform for teams that need scalable collaboration.” Those are different lanes, and the practical consequence of picking wrong is real: run your poster pipeline in a UI-design tool and you fight the tool; run your design system in a ten-template marketing editor and you rebuild it by hand.

The short answer, given the evidence available: pilot Doory for template-driven marketing collateral, keep vector, interface and design-system work in Penpot, and stay with hosted Canva if what you actually need is its ready-made template catalog. Budget for the paid plan if you take that route, because poliety reports that “Canva’s free tier gates templates, exports and brand tools behind a paid plan.” Every part of that recommendation comes with a condition, because every Doory capability claim in circulation traces back to the project’s own README. No benchmark or collaboration load test exists in the available coverage, and the hands-on reports that do exist are informal and negative.

What Doory actually ships, as project-reported

Doory’s own documentation positions it squarely at marketing collateral. The README says: “Doory is a full design editor that runs in your browser. Make posters, social posts, stories, slides, invitations, resumes, thumbnails and business cards: start from a template or a blank page, edit everything, and export to PNG, JPG, SVG, PDF, MP4 or GIF.” (GitHub)

The project-reported feature list is broad: layers, groups, masks, filters, curved text, snapping, rulers, multi-page designs, animation, audio, presenting, comments and real-time co-editing. On animation, the README reports 27 enter and exit animations, 12 emphasis effects and 16 page transitions, plus a built-in music and sound effects library. On export, the claim that matters most to a marketing team is this one: “PNG with transparency, JPG, SVG and PDF, plus MP4, WebM and animated GIF, all made in your browser. Need print? Get a print-ready PDF with bleed and crop marks.” (GitHub)

Treat all of that as a specification the project asserts, not a capability anyone has verified. The launch coverage restates it; one outlet, lavx.hu, goes further and asserts “full feature parity on animation, video export, and real-time collaboration” with Canva. There is no testing behind that phrase anywhere in the available coverage. It is an editorial rewrite of the README, and it should be read that way.

The counterweight is the community reception, and it includes people who ran the app. According to daily.dev’s summary of the Hacker News thread, “the discussion is dominated by skepticism that the project is almost entirely AI/Claude-generated from a near-empty commit history, with heavy doubts about code quality, stability, and the credibility of its marketing copy.” The same summary reports that “Testers reported crashes and said it felt like a low-effort, buggy clone,” and quotes one tester: “fully vibed low effort clone atually. it is now crashing while testing.” None of that is a benchmark or a load test, and AI-assisted authorship is not itself a defect. But crash reports from people who actually ran the editor carry more weight than abstract skepticism, and they mean the README’s claims have already failed informally for some users. That is exactly the state a pilot should assume.

The three-command promise and the surface underneath it

Doory’s deployment pitch is genuinely simple. The documented steps are:

cp .env.example .env # set DJANGO_SECRET_KEY (openssl rand -base64 48) and POSTGRES_PASSWORD
docker compose up -d --build
docker compose exec api python manage.py createsuperuser

(GitHub)

The README’s summary of what you get: “One docker compose up runs the app, the API, the database and live collaboration on your own server. Every design and upload stays under your control.” (GitHub)

Read that stack description as an operations commitment, not just a convenience. You are taking ownership of a Postgres instance (with a password you set and must protect and rotate), a Django application (with a secret key that gates session security, generated via openssl rand -base64 48 per the docs), and a websocket-backed live collaboration service. Three commands get it running; they do not back up the database, patch the images, or tell you what happens to a co-editing session when the API container restarts. For a small team already comfortable running Compose stacks, this is familiar territory, and a single Compose stack covering the app, the API, the database and the collaboration service keeps the footprint small. For a team whose Docker experience is “we run one container for the blog,” the maintenance burden is the product.

Independent coverage is blunt about the maturity picture. Kompozy’s launch write-up characterizes Doory as “early and independent (one main contributor, few releases) with only ten starter templates — capable, but not a funded product with Canva’s catalog or a support SLA.” One main contributor means the bus factor is one. Few releases means there is no established cadence for security fixes. No SLA means the support channel is an issue tracker. None of this disqualifies a pilot; all of it should shape what you point the pilot at.

Penpot’s lane is a different asset class

The evidence for the Penpot side of this comparison is thinner than the title implies, and it is worth saying so plainly: the available material on Penpot is its own homepage positioning, “the open-source design platform for teams that need scalable collaboration” (penpot.app). No published benchmark compares Penpot’s marketing-template workflow with Doory’s.

But the routing logic does not need a benchmark, because the two tools document different scopes. Penpot is built around interface design, vector work and team-scale collaboration on shared design artifacts. Doory’s documented asset types are finished marketing pieces: posters, social posts, thumbnails, flyers, business cards. These overlap on a canvas but not on a workflow. A design system with shared components, tokens and developer handoff is Penpot-shaped work. A sale post that needs to be an animated GIF by Friday is Doory-shaped work, if Doory’s export claims hold up.

The mistake to avoid is treating this as a migration. If your team already runs Penpot, Doory does not replace any of it. It would sit beside it as a production tool for the assets Penpot was never aimed at.

The hidden cost: you become the template library

Here is the part of self-hosting a design tool that the deployment commands do not mention. Canva’s stickiness is not its editor; it is the catalog. Doory ships with ten. The README lists them: “a gig poster, a wedding invitation, an event story, a sale post, a café flyer, a quote card, a resume, a YouTube thumbnail, a pitch deck and a business card,” each with its own palette and open-licensed fonts, fully editable (GitHub).

Ten well-made starters is a reasonable foundation for evaluating an editor. It is not a content supply. Every recurring asset your team produces beyond those ten starting points, every brand-consistent variation, every seasonal campaign set, is design labor your team now owns. On Canva, that labor is amortized across a funded catalog. On a self-hosted Doory instance, it is a line item in someone’s week. Kompozy makes the contrast explicit: “capable, but not a funded product with Canva’s catalog or a support SLA.”

This is the real tradeoff, and it is about content labor and infrastructure ownership, not license ideology. If your marketing output is a handful of recurring formats, building your own template set once is a manageable, even attractive, investment: your templates, your fonts, your server. If your output is varied and constant, the catalog gap will cost more than the subscription ever did.

There is also a scope boundary worth respecting. Doory, per Kompozy’s description, “produces individual assets on a canvas you drive by hand — it does not generate avatar video, clip long footage, write copy in a brand voice, or schedule and publish across platforms.” If your workflow depends on any of those, the comparison with hosted Canva ends there, regardless of hosting preferences.

One license detail that deploying teams miss

Doory is released under the Attribution Assurance License. Per the README, use, modification and redistribution (including commercial use) are allowed, but the license and NOTICE must be kept, and credit must be displayed prominently in the running app. This is not a reason to avoid the tool, but it is an obligation with a visible surface: if you strip the credit from the UI, you are out of compliance, and “we white-labeled it” is not a defense. Flag it to whoever owns the deployment before the first external user sees the instance.

The license may also close the door on contributions. daily.dev’s thread summary lists among the pushback that “the chosen license appears to require GPG-signed commits while providing no GPG metadata, making it effectively impossible to comply with when contributing.” If that reading holds, nobody can submit fixes without breaching the license, which compounds the bus-factor problem above: you would not just be adopting a single-contributor project, you would be adopting one that may be unable to accept your patches.

A routing table, with the confidence labels attached

Every cell in the Doory column other than deployment mechanics is project-reported, and the Penpot column rests on vendor positioning rather than assessed maturity. The Canva column describes the hosted product, not its free tier: poliety reports that “Canva’s free tier gates templates, exports and brand tools behind a paid plan.” That is the state of the evidence, not a rhetorical hedge.

What to test before committing anything

Because the only hands-on coverage so far is informal crash reporting rather than a benchmark or a collaboration load test, the verification step is yours. Three tests settle most of the decision, and all three map to claims that are currently README-only:

1. Co-editing under realistic concurrency. Real-time collaboration over websockets is the stack component most likely to degrade quietly. Have the team edit the same multi-page design simultaneously and watch for sync lag and dropped sessions, including what happens when the API container restarts mid-session.
2. Video and GIF export at production sizes. Browser-side MP4, WebM and animated GIF export is the feature that most distinguishes Doory from a vector tool, and browser-side rendering is exactly where memory limits and long export times bite. Export the largest animated asset you would actually ship.
3. Print PDF fidelity. Bleed and crop marks are binary for a print shop: either the PDF passes preflight or it does not. Send one export to your actual printer before routing any print work through the tool.

I would run this pilot against work that can tolerate a restart: internal event graphics, a social series with slack in the schedule. If a broken export or a lost co-editing session means rebuilding a customer’s campaign the night before launch, the missing independent verification matters more than anything on the feature list.

The verdict, and its limits

Route template-driven marketing assets to a small Doory pilot on your own Docker host. Keep vector, interface and design-system work in Penpot. Stay with hosted Canva if the ready-made catalog is what you need, and budget for the paid plan, since poliety reports that “Canva’s free tier gates templates, exports and brand tools behind a paid plan.” For avatar video, brand-voice copy or cross-platform scheduling, Doory’s documented scope does not reach, and the available coverage does not settle who covers them or at what price. The attention the launch drew, more than 120 Hacker News points within hours and 383 GitHub stars, measures interest, not stability, and the thread itself is where the provenance doubts and the crash reports live.

The limits of this recommendation deserve the same prominence as the recommendation. Every Doory capability, export and collaboration claim traces to the project’s own README and launch write-ups that restate it, and the only hands-on testing in the coverage is informal and negative; the Penpot side of the routing rests on documented positioning, not a head-to-head test; and the community’s code-quality questions remain open. This is a routing rule inferred from each project’s documented scope, plus a verification checklist for the claims that matter. If the three pilot tests pass, Doory earns a permanent seat for marketing assets. If they fail, nothing else about the project, the stars, the launch coverage or the deployment elegance, should change your answer.

Frequently Asked Questions

How many starter templates does Doory ship with?

Doory ships with ten. The README lists them: “a gig poster, a wedding invitation, an event story, a sale post, a café flyer, a quote card, a resume, a YouTube thumbnail, a pitch deck and a business card,” each with its own palette and open-licensed fonts, fully editable (GitHub).

What license obligation does Doory have for the running app?

Doory is released under the Attribution Assurance License. Per the README, use, modification and redistribution (including commercial use) are allowed, but the license and NOTICE must be kept, and credit must be displayed prominently in the running app. This is not a reason to avoid the tool, but it is an obligation with a visible surface: if you strip the credit from the UI, you are out of compliance, and “we white-labeled it” is not a defense.

What three tests should be run before committing to Doory?

1. Co-editing under realistic concurrency. Real-time collaboration over websockets is the stack component most likely to degrade quietly. Have the team edit the same multi-page design simultaneously and watch for sync lag and dropped sessions, including what happens when the API container restarts mid-session.
2. Video and GIF export at production sizes. Browser-side MP4, WebM and animated GIF export is the feature that most distinguishes Doory from a vector tool, and browser-side rendering is exactly where memory limits and long export times bite. Export the largest animated asset you would actually ship.
3. Print PDF fidelity. Bleed and crop marks are binary for a print shop: either the PDF passes preflight or it does not. Send one export to your actual printer before routing