PoseForge takes an identity photo, a separate pose reference and a set of creative controls, then prepares them for an image-generation engine. Its purpose is to make “put this person in that pose” a reusable workflow, with saved characters, a pose library and generation history, instead of a prompt that has to be rebuilt for every image. The project is available under the Apache-2.0 license on GitHub.
The project’s public introduction includes an October 27, 2026, Show HN submission. That submission provides a public announcement point, not a verified first-release date. The repository documents support for Codex CLI, Google Antigravity, local ComfyUI and hosted image APIs.
Where each part runs matters. PoseForge keeps its workspace, embedded database, libraries and generated files on your computer. Image generation can still involve a cloud provider. For creators handling recognizable faces, that boundary matters more than the local-first label alone.
How Identity and Pose References Work Together
PoseForge separates the person you want to depict from the pose and composition you want to create. An identity reference supplies the subject’s appearance; the pose reference supplies the visual arrangement. Camera, lighting, styling and fidelity settings add direction before PoseForge passes the prepared inputs to the selected engine.
The documented Studio workflow has three main stages:
- Choose the subjects. Upload references for one to four people, or select previously saved characters.
- Choose the pose. Upload a pose image, select one from the library or use the pose-collage splitting tools.
- Direct the result. Set the background, style and optional creative brief, select a ready engine, review the usage estimate and generate.
The user guide recommends clear, well-lit identity photos in which the subject is large enough to recognize. HEIC and HEIF uploads are converted for browser preview and processing.
Normal mode keeps the core workflow compact. Advanced mode exposes per-person direction, fidelity controls, camera and lighting settings, composition, retouching, aspect ratio, recipes and up to six queued variants. That gives creators a way to adjust one part of the request without rebuilding the entire setup.
According to the repository documentation, PoseForge prepares references locally: it normalizes images, can split multi-pose sheets and assembles the multi-image prompt before calling an engine. Saved characters can also carry per-character angle profiles.
I’d view that preparation layer as the project’s most useful contribution. It gives a creator a consistent place to manage references and direction across engines. It also makes an important limitation easier to understand: consistent inputs are a workflow feature, while consistent likeness remains dependent on the selected model. The project itself says output quality depends on the engine and model; the available evidence does not include independent identity-preservation measurements.
Uploaded poses are saved automatically for reuse. Characters have their own library, and selecting a saved character fills the next available subject slot. That makes the workflow particularly relevant to repeated portraits or multi-person compositions, where collecting the same inputs again is otherwise a substantial part of the job.
Local Storage and Local Inference Are Separate Choices
PoseForge’s privacy model has two distinct boundaries: where the workspace lives and where the image is generated.
The README says the embedded PGlite database, character library, pose library, workspace and generated files stay on the machine. It also says there is no PoseForge cloud service receiving the locally calculated usage metrics.
The generation boundary changes with the engine:
| Engine | Required setup | Where generation happens | What happens to selected references |
|---|---|---|---|
| Codex CLI | Installed, authenticated Codex CLI | Through the CLI provider | Selected references, prompt and settings go to the provider |
| Google Antigravity | Installed, authenticated Antigravity CLI | Through its provider connection | Selected references, prompt and settings go to the provider |
| Local ComfyUI | Running local server and an exported API workflow | Can run entirely on your machine | Can remain local when inference is fully local |
| Hosted APIs | Provider configuration and API keys | On the provider’s infrastructure | Selected references and generation inputs leave the machine |
The user guide names OpenAI, Gemini and Replicate as API options. Codex and Antigravity use the account and provider connection of their locally installed command-line tools.
A local CLI is therefore not evidence of local inference. It can launch work from your computer while sending the actual image-generation request elsewhere. Likewise, keeping a character library on disk does not prevent a selected character reference from being transmitted when you use a hosted engine.
For a generation involving several people, the practical privacy decision applies to the selected references for that whole request. Saving those people locally avoids placing the library itself in a PoseForge-hosted account, but it does not remove the provider transfer needed for a cloud generation.
A Practical Privacy Check Before Generating
The documented architecture suggests a simple decision process:
- Identify the selected engine. Local ComfyUI and a cloud-connected CLI have different data paths.
- Review the selected references. Those are the inputs the project says it sends for that generation.
- Check whether local inference is actually configured. Installing PoseForge alone does not install or configure a local image model.
- Review the provider’s rules when using cloud generation. The opened PoseForge documentation does not establish providers’ retention or training policies.
My view is that PoseForge’s local workspace is a useful privacy boundary, but it should not be treated as a blanket privacy guarantee. For sensitive portraits, the decisive choice is a fully local inference setup. For ordinary creative work where cloud processing is acceptable, local libraries and history still offer practical control over organization and storage.
How to Run PoseForge Locally
PoseForge requires Node.js 20.9 or later. Its database is embedded, so the documented setup does not require Docker or a separate PostgreSQL server.
The repository quickstart provides these commands:
git clone https://github.com/vishwakulkarni/PoseForge.git
cd PoseForge
npm install
npm run dev
These commands download the project, enter its directory, install the API and web dependencies, and start the development application. They are the project’s published instructions, not a setup independently executed for this article.
Open http://localhost:3000 after starting it. According to the README, the embedded PGlite database is created and migrated automatically on first launch.
The repository also documents an installation check:
npm run setup
The README describes this as an end-to-end check of a fresh installation, including the database and 16 bundled offline poses. Those bundled references let you explore the pose library without first supplying your own collection. Exploring the interface does not require a configured image engine.
The full studio runs locally. Its GitHub Pages presence is a landing page and documentation site, not a hosted version of the generation workspace.
Connect an Engine in Settings
Frequently Asked Questions
4 questions
1Is PoseForge Fully Offline?
It can support a fully local generation workflow with appropriately configured local ComfyUI inference. Codex, Antigravity and hosted API engines send selected generation inputs to their providers.
