Statically puts a CDN in front of your repository without a build step

A URL pattern instead of a hosting account

Statically is described as a free, fast global content delivery network for open-source projects, and its purpose is to help developers distribute static assets such as CSS and JavaScript libraries. The supporting platforms are GitHub, GitLab, Bitbucket and npm.

The mechanism is a URL scheme, not an upload. Instead of pushing your files to a hosting account, you rewrite the link to point at the CDN and it fetches from the repository for you. There is no dashboard to configure and no bucket to keep in sync, because the repository is the source of truth.

For GitHub the pattern is:

https://cdn.statically.io/gh/:user/:repo@:tag/:file

GitLab uses the gl prefix:

https://cdn.statically.io/gl/:user/:repo@:tag/:file

and Bitbucket uses bb:

https://cdn.statically.io/bb/:user/:repo@:tag/:file

The npm routes are slightly different because a package is a registry entry rather than a repository. There is a short form for the package itself and a versioned form for a file inside a specific release:

https://cdn.statically.io/npm/:package
https://cdn.statically.io/npm/:package@:version/:file

That the tag is part of the path is the detail that matters most. The URL is not a moving target, it is a specific revision, and pinning a tag in a link is the same discipline you would apply to any other immutable asset URL.

The feature list in the documentation is short and matches what the URL patterns do: a CDN for repositories on GitHub, GitLab and Bitbucket, and a CDN for npm packages.

Three limits that decide whether it fits your use case

The limitations section is explicit, and the three entries are the ones to check before you build anything on top of this.

Only public repositories are supported. There is no authentication in the URL scheme, so there is no way to serve a private repository, and that is a hard boundary rather than a configuration gap.

The file size limit is 25MB per file. For CSS and JavaScript libraries, which is what the documentation says the service is for, that ceiling is generous. It is not a ceiling for a distribution archive, a video asset, or a large data file, so a repository that also publishes binaries has to think about which assets it points at the CDN for.

In cases of abuse, rate limiting may be applied. This is the limit with the most bite in practice, and the one the documentation is least specific about, because it does not say what the threshold is, what the response looks like, or who decides. Rate limiting is applied to the client that requests too much, which in a bad case is every visitor to your documentation site if you have pointed a script tag at the CDN.

The practical response to all three is the same: use Statically for the small public library assets it is designed for, and keep the option of serving those assets yourself. A link to a CDN is a dependency you can lose at any time, and this one has an explicit policy for limiting your traffic.

What the repository shows about how the service is built

The source repository is the website and the edge logic, and the layout is informative.

The top-level entries include an app/ directory, which in a Next.js project is the router directory, a components/ directory, a lib/ directory, a public/ directory for static assets, styles/ and hooks/ directories, and a components.json file, which is the shadcn-style configuration. The package.json confirms the stack: it is a Next.js application with name statically, version 0.1.0, marked private, with scripts for next build, next dev, next start and eslint. React is at 19.2.0 and Next at 16.0.10.

Two files stand out. There is a wrangler.jsonc, which is the Cloudflare Workers configuration format, and a next.config.mjs, which is the Next.js configuration. Together they describe a Next.js application deployed to Cloudflare Workers rather than to a Node server.

That is a sensible architecture for this kind of service. The request handling for a CDN URL is a mapping from path to origin, with caching in front, and running that at the edge means the latency for a user in another continent is one hop rather than a cross-ocean round trip to a central origin.

The build tooling is also visible in the repository. The dev dependency on bun.lock indicates Bun as the package manager, postcss.config.mjs is present for CSS processing, and autoprefixer and tailwind-adjacent tooling appear in the dependency list alongside the Radix UI primitives and lucide-react for icons. The components.json and the large set of Radix UI packages suggest the landing page and any UI are built from the usual shadcn/ui style component set.

Sponsorship and governance for a service with no licence file

The contributing and sponsorship section says contributions are welcome and lists three ways to help. You can sponsor the project on Patreon. Companies are welcome to sponsor it with time, resources or services. And you can report bugs or suggest features through GitHub issues.

That last one is the only route into the codebase. The repository has no licence file among the top-level entries, and the licence field is not stated, which for a service that fetches and redistributes other people's files is the most consequential gap in this documentation. A CDN that caches and serves content from other people's repositories is a redistribution of their content, and the terms under which Statically is allowed to do that are not in the repository.

For a user, this matters in a narrow way. If you point a script tag at cdn.statically.io for a library your site depends on, you are depending on a service whose legal basis you cannot read from the repository. That is not a reason not to use it for a hobby project or a documentation site, but it is a question to ask before you put it in a commercial product's critical path.

The contact address given is [email protected], and the note invites questions about contributing or sponsorship, which is a reasonable route if you need the terms clarified.

How it compares to serving the file yourself

The obvious alternative is to serve the assets from your own domain, and the difference in approach is worth spelling out.

Serving from a repository host directly means a link to raw.githubusercontent.com or a GitHub Pages site. The difference is that those hosts are not a CDN in the general sense, they do not cache aggressively across regions for you, and for npm packages the unpkg and jsDelivr style services already fill that gap. jsDelivr in particular already serves npm packages and GitHub repositories over a global CDN, which is the same idea with a different URL shape.

The distinctive part of Statically is that it is a single vendor with one URL scheme covering four source platforms, and it is free for open-source projects, with sponsorship as the business model rather than a paid tier for larger traffic.

The cost of using it is giving up control. You cannot configure cache headers, you cannot purge a file, you cannot add a custom header, and if a file is removed from your repository the cached copy may outlive it. You also accept a rate limit you cannot read the terms of.

The cost of not using it is a build pipeline, a hosting account, and a domain, which is real work for a small project that just wants its README to load a stylesheet from somewhere fast. That is the trade the service is offering, and for open-source library authors it is often a good one.

An open-source project with a quiet commit history

The last push to the repository was on 2026-04-10, and the default branch is main. The repository publishes no GitHub releases, so there is no version to pin for the service itself.

For a service rather than a library, the commit history is the main maintenance signal, and it points in a particular direction. The package version in package.json is 0.1.0 and the project is marked private, which is consistent with an application that is deployed rather than published. The readme makes no claims about uptime, service level, or a support commitment, and the topics on the repository are cdn, css, javascript and open-source, which is a fair summary of the scope.

The absence of a releases list and the absence of a changelog mean that a reader cannot tell from the repository what changed or when a URL behaviour might have shifted. For a CDN, that is worth remembering in a specific way: the URL scheme is the API, and if the scheme ever changes, every link pointing at it breaks at once unless the old form keeps working. Nothing in the documentation promises that the paths are frozen.

None of this makes the service unsuitable. It makes it a service to depend on lightly, and one where keeping a local copy of what you serve is the sensible precaution rather than an overreaction.

Editorial conclusion

Statically suits an open-source project that wants a CDN for its released CSS and JavaScript files without operating one, and that accepts the trade of serving assets from someone else's cache of a public repository. It is the wrong choice for a private repository, for files above 25MB, and for a production application whose assets are built rather than committed, since Statically serves what is in the repository rather than running a build. Before pointing a site at it, check that every asset you intend to serve is committed at a tagged release rather than built during CI, and remember that the service can rate limit you, so keep a local copy of every asset you depend on.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. staticallyio/statically on GitHub