ALLWEONE presentation-ai: a self-hosted slide generator with an outline step you can edit

The problem is the first draft, not the slide editor

Most people who build a deck already have an editor. What they do not have is a starting structure. The README frames the tool as an alternative to Gamma.app and describes a workflow where AI produces content, but the design decision that matters is the ordering: the outline comes first, the user reviews it, and only then does generation run. That gate is the product. A generator that goes straight from topic to finished slides forces you to read the whole deck to find out whether the structure was wrong. Here you find out after one cheap step.

The audience implied by the setup instructions is a developer or a small team willing to run their own instance. PostgreSQL, Google OAuth credentials, and at least one AI provider key all appear in the prerequisites. That is not a consumer tool. It is also not a library you drop into an existing app; it is a full application with a database schema, authentication and file uploads. The topics list on the repository (ppt, powerpoint-generation, presentation-slides) matches that reading. If you wanted a component to embed, this is the wrong shape.

Outline, theme, then slides: the data flow the README describes

The usage section lays out a sequence rather than an architecture. You enter a topic, pick a text model, choose a slide count (the README suggests 5 to 10), select a language, and optionally toggle web search. You click Generate Outline. You edit the outline. You pick a theme, an image source (ai or stock), and a style (Professional or Casual). You click Generate Presentation and, per the feature list, watch it build in real time with auto-save running as you work.

So there are two generation passes with a human edit between them, and the second pass consumes the edited outline plus the theme and style selections. The persistence layer is PostgreSQL through Prisma, which is why the setup includes a db:push step and why auto-save has somewhere to write. Prisma Studio is exposed as a script, which suggests the schema is meant to be inspected directly during development. Text generation is described as pluggable across OpenAI, Together AI, Ollama and LM Studio; image generation draws on Together AI, FAL and Unsplash depending on whether you choose AI or stock images. Web search, when toggled, is attributed to Tavily. The editor itself is Plate, and drag and drop is DND Kit. None of this is unusual, and that is the point: the stack is legible to anyone who has shipped a Next.js app.

Getting it running: clone, env file, db:push, dev

The README gives a short path. Clone the repository over SSH, then pnpm install. Create a .env in the root. The documented keys are DATABASE_URL, NEXTAUTH_SECRET, NEXTAUTH_URL, GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, OPENAI_API_KEY, TOGETHER_AI_API_KEY, FAL_API_KEY, UPLOADTHING_TOKEN, UNSPLASH_ACCESS_KEY and TAVILY_API_KEY. The tip says to copy .env.example and fill in values, and adds that if you plan to use local text models through Ollama or LM Studio you can run text generation without an OPENAI_API_KEY.

Then pnpm db:push to initialize the database, pnpm dev, and open http://localhost:3000. The script list is worth reading before you start: pnpm build, pnpm start, pnpm db:studio, pnpm type for TypeScript checking, pnpm check and pnpm lint for Biome. Node 18 or higher is required, and a PostgreSQL database is required regardless of which model provider you choose. This is the part I would flag to anyone evaluating it casually: the app cannot run on SQLite or in-memory storage, so a local trial means running a Postgres instance first. The README does not say whether Docker Compose or any container recipe is provided, and no such file is mentioned in the material I have.

The local model path is advertised but not documented here

The strongest claim in the README is that you can run text generation without an OpenAI key by pointing at Ollama or LM Studio. The table of contents lists a Local Models Guide, and the usage steps list Ollama and LM Studio as text model options alongside OpenAI. What the README excerpt does not contain is the body of that guide: no base URL variable, no model name variable, no port, no example configuration. There is no OLLAMA_HOST or equivalent in the .env block.

That is a real gap for the exact user the feature is aimed at. Someone who wants to avoid sending prompts to a cloud provider has to read the repository to find out how the app discovers a local endpoint. I am not claiming it is broken; I am saying the setup instructions as given do not let you complete that path. Treat the local model support as a claim to verify in the source before you plan around it. The same caution applies to the image generation split: the README names Together AI and FAL as providers and Unsplash as a stock source, but does not map which key is needed for which image option.

Export and sharing are the parts that decide whether it fits

A generated deck is only useful if it leaves the tool. The feature list includes PowerPoint export to .pptx, a presentation mode inside the app, public sharing via a generated link, and recording with microphone and webcam controls. It also lists charts, infographics and media embeds, and PPTX theme import, which lets you pull theme inspiration out of an existing PowerPoint file rather than building a theme from scratch. With 38 built-in themes plus custom theme creation and saving, the theming surface is broad.

Two constraints follow from this list. First, public sharing means your generated content is reachable by link, which is a decision you make per presentation and worth knowing about before you put internal material into the tool. Second, PPTX export is a conversion, and the README says nothing about fidelity. If your downstream workflow depends on a specific layout surviving the round trip, export a test deck and open it in PowerPoint before you commit. The repository gives no release history in the material I have, so there is no changelog to check for export fixes.

Compared with a plain Markdown-to-slides pipeline

The obvious alternative for a developer is not another AI slide product. It is writing the deck as Markdown and rendering it with a tool such as Marp or reveal.js. The difference in approach is where structure comes from. With Marp, you write the structure yourself in plain text, commit it to the repository, diff it in a pull request, and render it with a command. There is no database, no OAuth, no provider key, and no outline generation step, because the outline is the source file.

presentation-ai trades that for generation and a visual editor. You get an AI outline, 38 themes, drag and drop, image generation and public links, and in exchange you take on PostgreSQL, Google OAuth, UploadThing and at least one AI provider. The Markdown route is better when the content is yours and you want the deck reviewed like code. The ALLWEONE route is better when the bottleneck is a blank page and you want a browser UI that non-developers on the team can also open. Neither is a superset of the other, and the choice is mostly about who edits the deck afterwards.

Licence, maintenance and what a fork actually costs

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement and, as always, this is a description of the licence text rather than legal advice; check the LICENSE file in your own copy if the terms matter to your organisation.

The maintenance cost is the interesting part, because MIT gives you the right to fork but not the labour. The app depends on Next.js, React, Tailwind, Prisma, NextAuth, Plate, Radix UI, DND Kit, UploadThing, and separately on OpenAI, Together AI, FAL, Tavily and Unsplash as external services. Each of those moves on its own schedule. Prisma schema changes and NextAuth version changes are the kind of upgrade that touches many files at once, and the README ships no migration strategy beyond pnpm db:push, which pushes the schema rather than generating versioned migrations. If you run this in production with real data, you will want to decide early whether you adopt Prisma's migrate workflow instead, because db:push is a development convenience. The repository shows no releases in the material I have, so there is no published upgrade path to follow. Budget for reading diffs yourself.

Editorial conclusion

Adopt it if you want a self-hosted deck builder where a human edits the outline before any slide is rendered, and you are willing to run PostgreSQL, Google OAuth and an AI provider yourself. Skip it if you need a documented offline setup or a hosted service with no infrastructure. Before committing, read the local models guide in the repository and confirm which environment variables the Ollama and LM Studio paths actually require, because the README does not list them.

Official sources

1. allweonedev/presentation-ai on GitHub
2. Issues
3. License: MIT
4. Project website
5. README