# AIMangaStudio: an AI comic pipeline that lives entirely in the browser

> A React 19 and Vite front end that calls Google GenAI directly for scripts, character sheets, storyboard layout and multi-page export, with no backend in the repository and no test suite.

**morsoli/aimangastudio** — An AI-powered tool for making comics, supporting script writing, storyboard/panel design and character style control. Visit: https://aimangastudio.liduos.com/

- Repository: https://github.com/morsoli/aimangastudio
- Website: https://liduos.com
- Stars: 1,488 · Forks: 255
- Language: TypeScript
- License: not declared
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/morsoli-aimangastudio

## A front end with no server behind it

The repository is small enough to describe in one sentence. It is a Vite application written in TypeScript that calls Google's generative AI SDK from the browser, and there is no server directory anywhere in the tree. The published app lives at `https://aimangastudio.liduos.com/`, and the project homepage is `liduos.com`, so the author is shipping this as a hosted single-page tool rather than as a library or a self-hosted service.

That decision has consequences worth naming before anything else. `package.json` lists exactly three runtime dependencies:

```json
"dependencies": {
  "react-dom": "^19.1.1",
  "react": "^19.1.1",
  "@google/genai": "^1.16.0"
}
```

There is no Express server, no database client, no ORM and no queue. Every function the README lists, from script generation to PDF export, has to run inside the page. For a creator experimenting with prompts this is a reasonable trade, since there is nothing to deploy except static files. It also means the API credentials have to be resolved somewhere in the client, and the repository does not include a `.env.example`, a serverless function directory, or any configuration file that shows how.

## What the tree reveals about the component layout

The file listing gives a clear picture of a conventional React application structure. The entry point is `index.html`, which loads `index.tsx`, and that file renders `App.tsx`. Beside them sit `vite.config.ts` and `tsconfig.json`, plus a root `types.ts` holding shared TypeScript definitions.

The interesting part is the four directories. `components/` holds the interface, `contexts/` holds React context providers, `hooks/` holds custom hooks, and `services/` is where the Google GenAI calls live. Splitting the AI calls out into `services/` rather than calling the SDK inside components is the right shape for a project of this kind, because it means the model configuration and prompt text sit in one place instead of being scattered through event handlers.

The `contexts/` directory tells you something similar. A comic tool has to hold the script, the character definitions, the style settings and the generated panels at once, and React context is how you carry that across panels without prop drilling. The README describes page-to-page continuity analysis as a feature, which is a stateful problem rather than a single-request one, so a shared store is a necessary piece rather than an architectural flourish.

Two other files sit at the root and are easy to miss. `logo.svg` and `og.webp` are the brand assets, and `metadata.json` sits alongside them. Four screenshots with Chinese filenames, covering script suggestions, character creation, style settings and batch export, are the entire visual documentation.

## What the README claims the four features do

The README is written in Chinese with English and Japanese versions linked from badges at the top. It describes the project as an end-to-end comic creation pipeline for independent creators and small studios, integrating story generation, panel layout, character definition and page-to-page continuity analysis.

The feature list has four numbered items. First, generating a comic script from natural language, covering plot, dialogue and narration. Second, character and style definition, with support for several drawing styles. Third, automatic AI panel layout, handling speech bubbles and shot changes. Fourth, multi-page export to PNG and PDF. The screenshots map one to one onto these four items, which is a sign the list describes what the app actually does rather than a roadmap.

Continuity analysis deserves a second look because it is the least obvious item. Keeping a character visually consistent across pages is the hardest part of any AI comic workflow, and the README names continuity between pages as a feature rather than leaving it as an implicit hope. Whether that works well in practice is something you can only judge by generating pages, and the README says nothing about how the consistency is enforced.

The target audience is listed as independent creators, comic enthusiasts, content studios and social media operators. The studio and social media entries are the interesting ones, because both suggest batch use, and batch use is where the client-side API key arrangement starts to matter.

## Running it locally takes two commands

The quick start section is short. It asks for Node.js, recommends version 18 or newer, and accepts either npm or yarn. Development is one command:

```bash
npm install
npm run dev
```

Building and previewing the production bundle is the pair the README documents next:

```bash
npm run build
npm run preview
```

Those two commands map directly onto the three scripts in `package.json`, which are plain Vite passthroughs with no environment validation, no type checking step and no bundler configuration beyond the defaults:

```json
"scripts": {
  "dev": "vite",
  "build": "vite build",
  "preview": "vite preview"
}
```

The absence of a type-check script is worth noting even though TypeScript is a dev dependency. `vite build` transpiles without type checking, so a type error would surface in an editor rather than in the build. The README does not mention running `tsc`, so nothing in the documented workflow catches type errors.

There is also no test script, no lint configuration and no test directory in the tree. The `.gitignore` and a `.claude/` directory are the only dot-entries. For a tool whose output is generated images, that absence is understandable, but it does mean nothing in the repository will tell you whether a change altered the rendered panels.

## Deployment buttons and a licence question

The README carries two one-click deployment badges, one for Vercel and one for Netlify, both pointing at the GitHub repository. That is a sensible default for a Vite app, since both platforms detect the framework and run the build script. It is also a signal about the intended audience: the author expects people to fork and deploy their own copy rather than share one hosted instance.

The licence story is less tidy. No licence identifier is set on the project page, and there is no LICENSE file in the tree listing. The README, however, ends with a licence section that states MIT. So the only statement about licensing is a line in the README, with nothing in the repository to back it up. If you plan to fork this and ship it commercially, that gap is the first thing to resolve, because a README assertion is not the same as a licence file.

The version field tells a similar story. `package.json` reports version `0.0.1` and marks the package as private, and the project has no published releases at all. Combined with the `0.0.1` number, that reads as software the author considers unfinished, which is consistent with a personal project rather than a maintained product.

## What the repository cannot tell you

The honest limit of this project is documentation. There is no docs site, no changelog and no contributing guide beyond a one-line invitation to open issues and pull requests. The README explains how to start the app and what the four features are, and stops there.

Several practical questions are therefore unanswered by the repository itself. Which Gemini model the app calls, and whether it is configurable, is not stated anywhere in the README or the dependency list. How the API key reaches the browser is not documented. What the export step actually produces, and at what resolution, is not described beyond the PNG and PDF formats. Whether generated panels are stored anywhere or discarded when the tab closes is also unstated, and the absence of any persistence library in the dependency list suggests they are not.

None of that makes the project unsuitable for its stated purpose. It makes it a prototype with a real feature set, aimed at the author and people who want to poke at it. The last push was on 2026-08-23, the repository is not archived, and the project description still points at a live hosted app, so the code corresponds to something currently in use.

For an evaluation, the repository tells you the shape of the thing and the deployed instance tells you whether the output is any good. Those are two different questions, and only one of them can be answered from the code.

## Conclusion

AIMangaStudio is a small, readable front end whose interesting decisions are all in the dependency list rather than in the code: Google GenAI called from the client, no server component, and no test script to keep the output honest. For an independent creator who wants to see whether AI-assisted panel layout holds up for their own series, cloning it, running `npm install` and `npm run dev`, and comparing three panels against a hand-drawn version is the fastest way to get a real answer. For anyone planning to run it for paying users, the missing pieces to price in first are the API key handling and the absence of any backend in the repository.

## FAQ

### What is AIMangaStudio and what does it generate?

It is a TypeScript web application for making comics with AI. The README lists four features: comic scripts from natural language prompts covering plot, dialogue and narration, character and style definition, automatic panel layout with speech bubbles, and multi-page export to PNG and PDF.

### What does AIMangaStudio use for its AI calls?

The package manifest lists `@google/genai` at version 1.16.0 as its only AI dependency, and the README names Google GenAI as the AI layer. The repository does not name a specific Gemini model or document how the API key is supplied.

### How do I run AIMangaStudio locally?

Node.js 18 or newer is recommended, then npm or yarn installs the dependencies. `npm run dev` starts the Vite development server, `npm run build` produces the bundle and `npm run preview` serves that bundle locally. The three scripts come straight from `package.json`.

### Can I deploy AIMangaStudio to my own hosting?

The README includes one-click deployment badges for Vercel and Netlify, both pointed at the GitHub repository. Since there is no server component in the tree, deployment is a matter of building the Vite bundle and serving the static output.

### What licence is AIMangaStudio released under?

The README states MIT, but no licence identifier is set on the project page and there is no LICENSE file in the tree. If you intend to fork it for commercial use, confirm the licence with the author rather than relying on the README line.

## Sources

- [Issues](https://github.com/morsoli/aimangastudio/issues)
- [morsoli/aimangastudio on GitHub](https://github.com/morsoli/aimangastudio)
- [Project website](https://liduos.com)
- [README](https://github.com/morsoli/aimangastudio/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/morsoli-aimangastudio