vikiboss/60s: a self-hostable API collection for daily news, trending lists and utility data

What vikiboss/60s actually solves

Most small apps need the same handful of non-core data points: a short news digest, a trending list, a gold price, a QR code. Each one normally means a separate scraper, a separate cache and a separate failure mode. The 60s API collapses that into one HTTP surface. The README describes the project as "a collection of high-quality, open source, reliable, globally CDN-accelerated open APIs" and lists the core feature as the daily 60-second news digest, backed by other endpoints for Olympic medal tables, Xiaohongshu, Bilibili, Weibo, Douyin and Zhihu trending lists, gold and oil prices, weather, translation, wallpapers, Epic free games, QR codes and Maoyan box office. The audience is developers building mobile news modules, site homepages, chat bot pushes, email digests or desktop notifications, as the README's use-case list states. The language of the data is Chinese, and that is not incidental. The news source is WeChat public accounts, so the product is aimed at Chinese-language consumers first.

Static JSON plus CDN, not a live scraper

The architecture is the part worth understanding before you deploy. The API process does not scrape Weibo or Bilibili on each request. According to the README's data-update section, a separate repository, vikiboss/60s-static-host, runs GitHub Actions on a schedule, uses the Gemini model to extract content, and writes static JSON files. The API server then serves those files through CDN caching. The README states the digest is retried every half hour and is normally updated by 10 a.m. That design explains the advertised millisecond responses: most requests are cache hits, not upstream fetches. It also defines the failure shape. If the scheduled job breaks, the API keeps answering with yesterday's data instead of returning an error, which is worse for a news widget than a visible failure. The scheduled workflow badge in the README is the only status indicator offered, and the README does not document a staleness field or a freshness header, so a consumer cannot tell from the response alone whether the digest is current.

Installing 60s with Docker and making the first call

The README marks Docker as the recommended self-hosting path and publishes the image as vikiboss/60s. The container listens on port 4399, and the package.json docker:run script maps the same port. Start it detached with a restart policy. The README's Docker block is:

docker run -d \
  --restart always \
  --name 60s \
  -p 4399:4399 \
  vikiboss/60s:latest

Once the container is running, the digest endpoint is the same path the public instance uses, /v2/60s. The README shows a plain JSON call, a text variant via encoding=text, and two image variants. The text form is the quickest way to confirm the service is alive and returning content:

curl "https://60s.viki.moe/v2/60s?encoding=text"

Substitute your own host and port for the self-hosted instance. For an image, the README distinguishes a redirect to the original CDN file (encoding=image) from a proxied binary response (encoding=image-proxy):

curl "https://60s.viki.moe/v2/60s?encoding=image-proxy" --output "$(date +%Y-%m-%d).png"

If you prefer not to run Docker, the README gives runtime alternatives. Deno and Bun each install dependencies and run their own entry file, and Node.js requires v22.6 or later because the entry point relies on type stripping:

# Node.js (需要 v22.6+)
npm install && node --experimental-strip-types node.ts

For Cloudflare Workers, the repository ships a wrangler.toml, so the README's command-line route is npm install followed by npx wrangler publish. The package.json dev script runs locally on port 4398 with DEV=1, which is a useful way to test changes without touching the container on 4399.

Where the 60s API breaks down

The README is explicit that the public instance at 60s.viki.moe has a daily request quota and strict rate limiting, and says it is intended for development and debugging only. That is the honest framing, and it means the public endpoint is not a production dependency. Self-hosting moves the quota problem to the upstream data repository, which you do not control: if the GitHub Actions job in 60s-static-host stops, your instance serves stale JSON. The second limitation is scope. Every data source named in the README is a Chinese platform or a WeChat public account, so an English-language news digest is not something this project provides. Third, the trending endpoints depend on the HTML structure of sites like Weibo and Zhihu. Cheerio is in the dependency list, which indicates HTML parsing, and scrapers of that kind break when a target site changes its markup. The README does not document a per-endpoint error contract, so a broken scraper may surface as an empty list rather than an explicit failure. Finally, if you only need one endpoint, such as a QR code, pulling in a multi-runtime TypeScript service with cheerio, fontkit and tyme4ts is more surface area than the task requires.

How 60s differs from RSSHub

The README's acknowledgements list RSSHub as an influence, and the comparison is instructive because the two projects solve overlapping problems from opposite directions. RSSHub turns sources into RSS feeds and expects you to bring your own reader or aggregator; the output format is a feed, and the consumer decides how to render it. The 60s API returns JSON, text or image directly from its own endpoints, with the digest pre-processed by a language model rather than passed through raw. That means less work on the client and less control over the shape of the data. RSSHub's route model is per-source and extensible by contributors who add routes; the 60s API's surface is a fixed list maintained by the project. If you need a feed your existing tooling already understands, RSSHub fits. If you want a ready-made digest and trending lists as JSON for a custom UI, the 60s API removes a processing step. The trade-off is that you inherit the project's editorial choices about which fifteen stories matter.

Licence, maintenance and the cost of upgrading

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position, and it places no copyleft obligation on your own code. It also means no warranty is offered, which matters for a service that aggregates third-party data: the licence does not transfer any rights to the underlying news text or platform data, and those sources have their own terms that the repository does not address. On maintenance, the last push was on 2026-09-10 and the most recent release listed is v2.54.0 from 2026-08-03, so the project is being worked on. Upgrades are versioned through bumpp, and the package.json release script runs it, so releases follow semantic versioning. The practical upgrade cost is low for Docker users: pull vikiboss/60s:latest and restart. Cloudflare Workers users are told in the README that syncing with the main repository is enough to update, because the Workers configuration is pre-set in the repo. The larger cost is not the upgrade itself but the dependency on the external data repository, which is a separate project with its own schedule.

Editorial conclusion

Adopt it if you want a single self-hosted endpoint for Chinese-language daily news and trending data, and you are willing to run the container yourself. Do not adopt it if you need a contractual uptime guarantee or English-language sources, because the data sources are WeChat public accounts and Chinese platforms. Before wiring it into production, verify that the upstream data repository is still updating, check which endpoints your deployment actually exposes, and confirm the rate limits you will hit.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vikiboss/60s on GitHub