HisMax/RedInk: a Xiaohongshu image-and-text generator you run yourself

The gap RedInk fills between an idea and a finished Xiaohongshu post

Writing a Xiaohongshu post is not one task. It is an outline, a cover that carries the hook, several content pages whose text renders correctly inside an image, and a visual style that holds across all of them. Doing that by hand means writing copy, then prompting an image model page by page, then checking that the Chinese characters in the generated image are actually the characters you wrote. RedInk compresses that loop into a single input sentence. The README describes the promise as "One Sentence, One Image: Generate Xiaohongshu Text and Images." The intended user is a solo creator or a small content team that already pays for model access and wants the assembly step automated. It is not a hosted SaaS: the repository is the product, and the official site at redink.top is the project's front door rather than a managed service you sign into.

How the outline, cover and page generation pipeline is wired

The architecture is a Flask backend serving a built Vue 3 frontend, with two separate provider configs because text and images come from different services. Text generation goes through text_providers.yaml, which supports an openai_compatible type and a google_gemini type. Image generation goes through image_providers.yaml, which supports google_genai for Gemini image models and image_api for OpenAI-compatible endpoints. The flow the README documents is three steps. First, an outline is generated, and the changelog for v1.4.3 states the default outline length is five pages when the user does not specify a page count. Second, the cover page is generated. Third, content pages are generated in batch. Each page in the outline can be edited, reordered, and given a custom per-page description, which the README marks as highly recommended. Individual pages can be regenerated without redoing the whole set. The v1.4.3 changelog notes that image provider logic was modularized into a provider policy, API client, response extractor, rate limiter and history image merger, which is the layer that decides how many requests go out at once and how returned images are stored.

Installing RedInk with Docker and generating your first post

The README recommends Docker and gives a single command. The image is histonemax/redink:latest, the container listens on port 12398, and two volumes persist state: history for the record of past generations and output for the generated images. Run it, then open the address and configure an API key on the Settings page, because the container deliberately ships without any keys.

docker run -d -p 12398:12398 -v ./history:/app/history -v ./output:/app/output histonemax/redink:latest

If you prefer compose, the repository includes a docker-compose.yml that maps the same port and volumes and sets restart: unless-stopped. The compose file also shows two commented volume lines for mounting your own text_providers.yaml and image_providers.yaml, which is how you avoid re-entering keys after a container rebuild.

docker-compose up -d

For a local build instead of the image, the README lists Python 3.11+, Node.js 18+, pnpm and uv as prerequisites. Copy the two config templates, install backend and frontend dependencies, then either run the platform start script or launch the two processes by hand.

cp text_providers.yaml.example text_providers.yaml
cp image_providers.yaml.example image_providers.yaml
uv sync
cd frontend && pnpm install

Starting manually means running the backend module and the Vite dev server in separate terminals. The backend serves on port 12398, the dev frontend on 5173. The README notes that the one-click start scripts open the browser at http://localhost:5173 automatically on macOS, Linux and Windows.

uv run python -m backend.app

A minimal image provider entry looks like the block below: the type selects the adapter, high_concurrency controls whether pages go out in parallel, and the model name must match what your account can call.

active_provider: gemini
providers:
  gemini:
    type: google_genai
    api_key: AIzaxxxxxxxxxxxxxxxxxxxxxxxxx
    model: gemini-3-pro-image-preview
    high_concurrency: false

After configuration, the first real use is one sentence typed into the generator, which returns an editable outline. Expect the outline step to take 15 to 30 seconds, per both the README notes and the v1.4.3 loading copy. Keep the page open while images generate.

High concurrency, rate limits and the failure mode the README warns about

The most concrete limitation is quota pressure. High concurrency is off by default, which generates images one at a time and suits "GCP $300 trial accounts or rate-limited APIs." Turning it on generates up to fifteen images in parallel and is faster, but the README states it requires API support for high concurrency and explicitly warns that it is not recommended for GCP $300 trial accounts because it may trigger rate limits and cause generation failures. That is a real trade-off, not a footnote: the default is slow precisely because the fast path breaks on the cheapest tier of access. Two other constraints matter. The container includes no API keys, so a fresh deployment produces nothing until someone configures a provider, which makes RedInk unsuitable as a zero-setup tool for non-technical users. And the pipeline is entirely dependent on remote model calls, so an outage or an exhausted quota stops generation mid-post; the README does not document a retry or resume mechanism for a partially generated set, only per-page regeneration after the fact. Finally, the notes tell users to be aware of Gemini and image API quotas and to be patient during image generation, which is a polite way of saying long waits are expected.

RedInk compared with assembling the same post by hand

The honest alternative is not another repository. It is doing the work directly: write the outline in an editor, then call an image model once per page, then paste the images into Xiaohongshu yourself. That approach gives you total control over every prompt and costs nothing beyond the same API usage. What it does not give you is the per-page description field, the reorder step, batch generation of the content pages, or the history and output directories that keep past generations on disk. RedInk's value is the orchestration layer around the model, not the model itself, and the changelog shows that layer is where the engineering effort goes: v1.4.3 fixed GPT Image and Nano Banana compatible image APIs by omitting response_format by default and supporting b64_json and data URLs. If your workflow is one or two images a week, the manual route is simpler. If you are producing multi-page posts regularly and want a consistent cover style, the batch path earns its setup cost.

Licence, maintenance and what an upgrade actually costs

The repository's LICENSE file is present but GitHub reports the licence as NOASSERTION, while the README badge points to CC BY-NC-SA 4.0. Those two signals do not fully agree, and the non-commercial clause in that licence is the part that decides whether RedInk can sit inside a commercial product. Treat that as a question for your own legal review rather than something to assume either way. On maintenance: the repository is not archived, and the last push was on 2026-06-30, which is roughly two and a half months before this writing. The only release note available is v1.4.3, dated 2026-06-30, so the project has a changelog but no retrieved release history beyond that entry. Upgrading the Docker deployment is mostly a matter of pulling histonemax/redink:latest again, but the two mounted config files are the upgrade risk: if a new version changes provider keys or adapter types, a custom text_providers.yaml or image_providers.yaml carried across the upgrade is what breaks first. The compose file's commented volume lines are the place to check before pulling.

Editorial conclusion

RedInk fits creators and small teams who already hold Gemini or OpenAI-compatible API keys and want a repeatable pipeline from one sentence to a multi-page Xiaohongshu post, with history and output persisted in mounted volumes. It does not fit anyone without image-generation API access, anyone on a GCP $300 trial account who intends to leave high concurrency on, or anyone who needs an offline generator, since the container ships no API keys and every page depends on a remote call. Before adopting it, verify three things: that your image provider returns b64_json or data URLs, since v1.4.3 changed how response_format is sent; that your quota survives concurrent generation of up to fifteen pages; and that the CC BY-NC-SA 4.0 licence terms suit your use, because the non-commercial clause is the boundary that decides whether this is a tool you can ship inside a paid product.

Frequently asked questions

Official sources

1. HisMax/RedInk on GitHub
2. Issues
3. Project website
4. README