ServerlessWP: running WordPress on Vercel, Netlify or AWS Lambda

The premise: a WordPress site without a server

ServerlessWP opens with a blunt position. WordPress hosting is silly, and the question it asks is why a small WordPress site needs a server running around the clock. The answer it gives is that ServerlessWP enables low maintenance and low cost or free WordPress hosting on Vercel, Netlify, or AWS Lambda. The mechanism is that WordPress runs on demand in serverless functions, with a SQLite database stored in S3 or Vercel Blob, so there is no always-on server and no separate database hosting to manage. The primary language of the repository is PHP, since WordPress is PHP, the licence is GNU General Public License v3.0, the homepage is serverlesswp.com, the last push was on 2026-10-16, and the repository has no GitHub releases. The package itself is named serverlesswp-wordpress-starter and depends on the serverlesswp package at 0.7.1 or newer, with node 22.x as the engine requirement.

The one click deploy, and the two settings to leave alone

The fastest route is the Vercel deploy button, and the README points it at a template that includes a private Vercel Blob store for the SQLite database and media uploads, so there is no separate database hosting and no credentials to copy. The link carries pre-filled environment settings for the stream provider and the Blob access mode, and the README tells you to leave the two pre-filled deploy settings as they are to enable media uploads. Once deployed, you open the site URL and complete the ordinary WordPress setup. Two of the Vercel features are called out as working in your favour here: CDN delivery with automatic HTTPS, and DDoS protection and firewall tools, both in the same place. Optional Web Analytics adds visitor insights once enabled with a tracking script in WordPress, though the README is careful to note that features and usage limits vary by plan, and that the free Hobby plan is for personal, non-commercial projects.

Which database, decided by which variables you set

The database choice is not a dropdown. It is inferred from the environment, and the README gives the selection order explicitly. MySQL wins if all four of its connection variables are set. Otherwise SQLite in S3 is used when SQLITE_S3_BUCKET is set, and SQLite in Vercel Blob when BLOB_STORE_ID, SQLITE_BLOB_STORE_ID or SQLITE_BLOB_READ_WRITE_TOKEN is set on Vercel. If none of those conditions are met, the setup page appears so you can choose. The Vercel Blob variables have specific roles, and the table spells them out. BLOB_STORE_ID is the connected store ID supplied by Vercel, SQLITE_BLOB_STORE_ID is an optional database specific store that overrides it, and SQLITE_BLOB_READ_WRITE_TOKEN is an optional static token instead of OIDC, with the note that the database does not use BLOB_READ_WRITE_TOKEN. SQLITE_BLOB_PATHNAME is the database base name and defaults to wp-sqlite. The store has to be private, and each new git branch starts with its own fresh SQLite database.

S3, R2 and the other storage route

The S3 route is the more portable of the two, and it works on Netlify, AWS and Vercel. The README asks you to create a private S3-compatible bucket, including Cloudflare R2, preferably near your functions. The environment variables for it are a bucket name, an API access key, an API secret key and a region. The same private-bucket rule applies here as on Vercel, and the reason is the same in both cases, since the file holds the entire site database and it must not be publicly readable. There is also a Netlify option to bring your own SQLite with S3 or your own MySQL, and an AWS Lambda option that deploys with the Serverless Framework.

What the project lets you customise, and where the boundaries sit

WordPress itself lives in a wp/ directory, and customisation follows the git model rather than a control panel. Plugins go into wp/wp-content/plugins/ and themes into wp/wp-content/themes/, and then you commit and push to redeploy. Media uploads and supported plugin generated files persist in S3 or Vercel Blob, and the README points at the stream wrapper reference for the file storage limitations, which is the section to read before you install a plugin that writes files. Caching is handled with cache headers such as s-maxage, and the README links the Vercel edge caching and Netlify cache header documentation. On the request side, api/index.js imports the WordPress handler from the serverlesswp-node package, and the README is explicit that the package owns runtime behavior and request hooks, while routing is configured in vercel.json or netlify.toml. That split is worth understanding, because it means the runtime behaviour of your site lives in a dependency you do not edit, and your deployment shape lives in a config file you do.

Keeping WordPress current, and where the README is explicit about limits

The maintenance story is one of the better arguments for the project. The README says that WordPress updates arrive as pull requests you can review and merge, so the usual maintenance task of logging into a server and clicking update becomes a code review, and the wp:update script in package.json is the entry point for that flow. The limits are stated just as plainly. The project is described as experimental, best suited to blogs, portfolios, documentation, marketing and small business sites, as well as dev or staging sites. SQLite keeps setup simple for sites with light database activity, but some plugins are incompatible and competing database writes can fail, and for multiple active editors, frequent form submissions, ecommerce, membership sites or forums, the README directs you to MySQL. The taxonomy of who should not use this is the most useful sentence in the whole document, because it names the failure mode before you hit it.

The alternative, and the decision to make first

The alternative to weigh is ordinary managed WordPress hosting, where a provider runs PHP and MySQL for you and you pay a monthly fee for the privilege. The difference in approach is that ServerlessWP removes the always-on compute and replaces it with function invocations, and moves the database from a database server to an object file in a bucket. What you gain is a hosting bill that scales with traffic and nothing to patch at the operating system level. What you give up is the database that can handle concurrent writes, the plugin ecosystem that assumes a real MySQL, and the predictable long-running process model that WordPress core and most plugins were written against. The most telling piece of evidence is the repository's own package.json, where the starter is a thin wrapper with one dependency and a single script, which tells you the complexity has been pushed into the serverlesswp package rather than eliminated. If your site is a blog, the trade is good. If it is anything with accounts, comments and carts, the README has already told you the answer.

Editorial conclusion

Adopt ServerlessWP if you run a low traffic WordPress site, or a staging environment, and you want to stop paying for an always-on server and a separate database host, since the SQLite file and uploads live in object storage and the compute only runs on demand. Do not adopt it for ecommerce, forums, membership sites or anything with several active editors, because the README says some plugins are incompatible and competing database writes can fail. Before you deploy, decide which database option you are using, since the selection follows a fixed order of environment variables, and if you need MySQL you must supply that database yourself.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mitchmac/ServerlessWP on GitHub
4. Project website
5. README