Mini-Cover: a Vue cover image generator that runs entirely in the browser

A cover generator with no backend and two runtime dependencies

Mini-Cover is a modern cover generation tool designed for blogs, short video and social media, supporting multiple customisation options so you can create personalised cover images. The README calls it an elegant online cover generation tool.

The repository description is in Chinese and says the same thing: a simple online cover generation site, built specifically for blogs, short video and social media, for generating personalised cover images.

What is worth noticing immediately is that there is no server component. The dependency list has two runtime entries.

  "dependencies": {
    "@iconify/vue": "^4.1.2",
    "vue": "^3.4.21"
  },

Vue for the interface and Iconify for icons. Everything else is a build dependency: the Vite plugin for Vue, Autoprefixer, PostCSS, Tailwind CSS and Vite itself.

Two runtime dependencies tells you a lot about how the tool works. There is no image processing library, no canvas library, no rendering server and no database. The cover is composed in the browser from HTML and CSS, drawn by the browser itself, and the result is whatever the user saves from the page. That is the whole architecture, and it is why the deployment story is so simple.

The project is a Vue 3 application, the primary language is Vue, and the licence is MIT with a LICENSE file at the root. The last push was on 2026-06-22 and there are no GitHub releases, so the version lives in package.json as 1.0.0 rather than in a tag. The live demo is at cover.bsgun.cn.

Configuration is split between the environment file and one config module

The configuration section is short and the split is worth understanding before you change anything.

Site base content is customised by modifying the .env file, and the .env file is committed to the repository, so the shipped defaults are the ones you start from.

Default text and font configuration live in src/config.js, and the README shows the module in full.

export const defaultConfig = {
    // 默认文本配置
    text: '默认标题',       
    watermark: '@水印文本', 

    // 字体配置
    fontFamily: import.meta.env.VITE_APP_FONT_FAMILY,
    
    // 可用字体样式列表
    fontStyles: [
        'https://font-cdn.com/font1.css',
        'https://font-cdn.com/font2.css',
        // ...
    ],
    
    // 字体选项
    fontOptions: [
        { value: 'default', label: '默认全局' },
        { value: 'Microsoft YaHei', label: '微软雅黑' },
        // ...
    ]
};

Three things come out of that. The default title text and the default watermark are plain strings in the source, so changing them is editing code, not configuration. The default font family comes from an environment variable through Vite's import.meta.env, with the VITE_APP_ prefix that Vite exposes to client code. And the available fonts are two parallel lists: fontStyles is a list of stylesheet URLs to load, and fontOptions is the list of choices presented to the user.

That two-list arrangement is the part that will bite you if you add a font. The URLs are remote stylesheets, so the page fetches them from another origin at runtime, and fontOptions only sets the label shown for each choice. Add a stylesheet to fontStyles and you also need an entry in fontOptions for it to be selectable, and the two lists are not cross-checked by anything in the repository.

The env var naming convention, VITE_APP_FONT_FAMILY, suggests there are other VITE_APP_ variables for the rest of the site content, since the .env file is described as holding the site base content.

So there are two edit points when you deploy your own instance: the environment file for the site copy, and the config module for the defaults that appear in the editor before the user touches anything.

The features are the editor, and the preview is the product

The feature list describes an editing interface rather than a set of integrations, and each item is a small design decision.

Responsive design with full mobile support, which matters because a cover tool is used on a phone more often than on a desktop. A rich icon library with one-click selection, which is where the Iconify dependency earns its place. Custom background images with drag and drop upload, so you drop a photo onto the page rather than navigating a file picker. Flexible title editing with a choice of fonts.

Then the two that shape how the tool feels. Watermark effect adjustment with live preview, and a clean operating interface that is quick to get the hang of.

The live preview is the mechanism underneath all of them. Because the cover is composed in the browser, every change to the title, the font, the background or the watermark is re-rendered immediately with no round trip. That is what makes the watermark adjustment feel like adjustment rather than like previewing a separate generation step.

The drag and drop upload is worth a second look too, because it has a consequence. A dropped file has to be read into the page to be drawn as a background. In a browser, the way to do that without a server is the FileReader API or an object URL, and either way the image data stays on the client. That is consistent with a project whose whole runtime dependency list is Vue and an icon package, and it is the reason there is no upload endpoint anywhere in the repository.

The typography defaults suggest the audience. The default title text is a placeholder in Chinese, the default watermark is a placeholder handle, and the first named font option after the default global is Microsoft YaHei, the standard Chinese system font. The site was built for Chinese content, and the font list is expected to be extended with fonts appropriate to that audience.

The repository layout matches a single page app: an index.html at the root for Vite to load, src/ for the application, public/ for static assets including the favicon.svg shown in the README header, plus vite.config.js, tailwind.config.js and postcss.config.js. There is no server directory, no api directory and no test directory.

Three commands, and the build output is a folder of static files

The quick start section is the standard Vite sequence, and the prerequisites are stated plainly: Node.js 16.16.0 or newer and NPM 8.15.0 or newer.

# 克隆项目
git clone https://github.com/JLinMr/Mini-Cover.git

# 安装依赖
npm install

# 启动服务
npm run dev

# 构建生产版本
npm run build

The three scripts map to the three entries in package.json: dev is vite, build is vite build and preview is vite preview. The dev server gives you hot module replacement while you edit, the build produces the production bundle, and preview serves that bundle locally so you can check the built output rather than the dev server.

The build output goes into the dist directory, and the README says it can be deployed directly to any static file server. That is the key operational fact about this project. There is nothing to install on a server, no database to provision, no environment to configure at runtime and no process to keep alive. A dist folder behind nginx is the entire deployment.

The README goes further than that and shows deployment buttons for three specific hosts. There is a Vercel clone button, an EdgeOne Pages button that carries the repository URL along with output-directory=dist, install-command=npm install and build-command=npm run build, and a Netlify deploy button. So the maintainer has already worked out the configuration for each of those platforms, which means a first deployment is a button press rather than a configuration exercise.

The EdgeOne button is worth a second look because of the sponsorship note. The README states that the project's CDN acceleration and security protection are sponsored by Tencent EdgeOne, which provides a long-term free plan with unlimited traffic and requests, covering mainland China nodes, with no overage charges at all.

That matters for a project whose users are mostly in mainland China, because the usual trade-off for a free static host is that it is either slow or capped there. The sponsor arrangement is what makes the demo at cover.bsgun.cn fast for its actual audience, and it is also a dependency worth knowing about: a project that depends on a commercial sponsor for its delivery is taking a free service rather than providing one.

Where Mini-Cover is the wrong tool

The first wrong-tool case is a team that needs covers generated in bulk. There is no server and no rendering queue, so producing two hundred covers means a person clicking two hundred times. The architecture that makes the tool pleasant to use and trivial to deploy is the architecture that rules out batch generation, and if you need volume this is the wrong shape.

The second case is an organisation that needs brand templates enforced. The default title, watermark and font options are edited in source and in a .env file, which is a per-deployment edit rather than a per-user choice with a lock. If your covers have to carry an approved logo, an approved font list and a fixed watermark, the enforcement has to live somewhere else, and this project has no mechanism for it.

The third case is a product that needs the cover generated on the server. There is no headless rendering path here, no image export API and no way to produce a cover without a browser. If your product generates covers as part of a publishing pipeline, you would need to run a browser somewhere, and this repository does not help with that.

The fourth case is a team with a strict network policy. The font list is a set of remote stylesheet URLs fetched by the page at runtime, so the cover editor depends on third-party font hosts being reachable from the user's browser. Where outbound requests are restricted, or where a compliance rule forbids pulling stylesheets from unknown origins, the font picker degrades.

On the dependency versions, there is a mismatch worth flagging. The README asks for Node.js 16.16.0 or newer and NPM 8.15.0 or newer, while the dev dependencies are Vite 5, Tailwind 3 and the Vue Vite plugin 5, and Vue itself is declared as 3.4.21. Vue 3.5 is what the README badge advertises. So the runtime dependency and the tooling sit at different major lines, and the Node floor in the README is the floor for the Vite 5 toolchain rather than for the current Vue release. Anyone building on Node 16 would also be several years behind on Node support itself.

There is also no test infrastructure. There is no test directory in the repository listing and no test script in package.json, so the editor's behaviour is verified by hand and by the live demo. For a tool whose entire value is visual output, that is a gap that a screenshot test would close quickly.

On licence, MIT with a LICENSE file at the root, so you can fork it, self host it and change the branding without any obligation beyond keeping the notice. The .env file being committed is worth a look before you fork, since it means whatever is in there ships with your copy.

Editorial conclusion

Mini-Cover suits a writer or a video producer who wants a quick cover image without an account, a server or a rendering queue, since the whole thing is a static page that runs in the browser and the build output is a dist folder you can host anywhere. It does not suit a team that needs batch generation, branded templates enforced centrally, or server-side rendering of covers, because there is no backend in this repository. Before adopting, read src/config.js and the .env file, because the default title text, the watermark and the font family are all configured there, and the font list is a set of remote stylesheet URLs your page will fetch at runtime.

Frequently asked questions

Official sources

1. Issues
2. JLinMr/Mini-Cover on GitHub
3. License: MIT
4. Project website
5. README