Short answer: Google Cloud Run can serve an RSS feed from a small container: a web process that builds the XML from your content, returns it with the RSS content type and a cache lifetime, and scales to zero when nobody is asking. Keep the feed handler stateless, read content from a database or storage bucket, set cache headers so a CDN or the browser can reuse the answer, decide whether to keep one instance warm and give the service a public address that never changes. An auto-poster such as PostRSS can then read the feed and share each new item on social networks.
Cloud Run runs containers on demand. You package a web application, deploy it and pay mainly for the time it spends handling requests. That model suits an RSS feed well, because a feed is a small, read-only document that is requested often but computed quickly. It also fits teams that publish content from a headless system, a spreadsheet or a database and have no traditional web server to host a feed. This guide shows how to build a feed service on Cloud Run, which settings matter for a document that tools fetch around the clock, and how to avoid problems with cold starts, caching and addresses. The commands and console names change over time, so check the current documentation of the platform for exact labels.
Cloud Run is a good fit when the content lives outside a classic web server. A static site generator publishes pages to a bucket, a headless content system keeps articles in an API, or an application stores products in a database. In each case you need a small piece of code that turns records into XML. You could place that code in a function, but a container gives you any language, any library and the same image on your laptop and in production. It is less suitable if your site already runs on a platform that produces a feed, such as WordPress, where the built-in feed is simpler and safer than a custom service.
The service needs one route. The example below uses Node.js and the Express library, but the structure is the same in any language: read the latest items, build the XML, set the headers and respond.
English
Lietuviškai
Deutsch
Français
Русский
Español
Polski
Italiano
Українська
Čeština
Português
日本語
Latviešu valoda
Eesti
Magyar
Bahasa Indonesia
Türkçe
हिन्दी
Ελληνικά
العربية
ไทย
Tiếng Việt
Română
Bahasa Melayu
বাংলা
import express from "express";
import { getLatestPosts } from "./content.js";
const app = express();
const SITE = "https://example.com";
const esc = (s) => String(s)
.replace(/&/g, "&" + "amp;")
.replace(/</g, "&" + "lt;")
.replace(/>/g, "&" + "gt;");
app.get("/feed.xml", async (req, res) => {
const posts = await getLatestPosts(30);
const items = posts.map((p) =>
"<item><title>" + esc(p.title) + "</title>" +
"<link>" + SITE + "/" + p.slug + "/</link>" +
"<guid isPermaLink='true'>" + SITE + "/" + p.slug + "/</guid>" +
"<pubDate>" + new Date(p.published).toUTCString() + "</pubDate>" +
"<description>" + esc(p.summary) + "</description></item>"
).join("");
const xml = "<?xml version='1.0' encoding='UTF-8'?><rss version='2.0'><channel>" +
"<title>Example blog</title><link>" + SITE + "</link>" +
"<description>News from Example</description>" + items + "</channel></rss>";
res.set("Content-Type", "application/rss+xml; charset=UTF-8");
res.set("Cache-Control", "public, max-age=300, s-maxage=300");
res.send(xml);
});
app.listen(process.env.PORT || 8080);Two details matter here. The service listens on the port given in the environment variable, because the platform decides it. And every text value passes through an escape function, because one stray ampersand in a title makes the whole feed invalid.
A short image file is enough. Use a small base image, install only production dependencies and start the server.
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]You can deploy from source or from an image in a registry, using the command line tool or a build trigger connected to your repository. After the first deployment the service receives a stable address from the platform, which you can map to your own domain such as feeds.example.com. Choose the region closest to your content store and to most readers.
A cold start happens when a request arrives and no instance is running. The platform starts the container, your code boots, and the first answer takes longer than the following ones. For a document that tools fetch on a schedule, a slow answer is usually harmless, but some clients give up after a few seconds. Keep the image small, avoid heavy work at start-up, create database connections lazily and reuse them between requests. If the delay is still a problem, set a minimum of one instance or put a cache in front of the service.
The cache headers in the example let browsers and shared caches reuse the answer for a few minutes. A content delivery network in front of the service is the best way to protect it from bursts. The simplest option is a global load balancer with caching enabled for the feed path. Another is to keep the feed on a CDN you already use and treat Cloud Run as the origin. Whatever you choose, make the cache key the path alone, so that query strings added by tools do not create new copies; the same ideas are explained for edge networks in the guide to a Cloudflare Workers feed. When you publish an article, either wait for the lifetime to expire or purge the feed path.
A container can be stopped and replaced at any moment, so the feed service must not keep anything it cannot rebuild. Read the latest items from the database, an API or a bucket on every request, or keep a short in-memory copy that is refreshed after a minute. Do not write files to the local disk and expect them to exist later. If you keep the entire feed in a storage bucket, generated by a build step after each publication, the service becomes even simpler: it can redirect or proxy to the file. A comparable serverless pattern is shown in the guide to an AWS Lambda feed.
Database passwords and API keys belong in the secret manager, mounted as environment variables or files, and never in the image or the repository. Give the service its own account with the least permissions it needs: read access to the data and nothing else. The feed itself is public, so make sure that no private item can reach it by accident. Filter by status in the query, not in the template, and test with a draft article to confirm that it does not appear.
The address the platform gives you is stable, but it is long and it belongs to the platform. A feed address becomes part of your public presence: it is stored in readers, in search tools and in the settings of every auto-poster. Map a domain or subdomain that you control, let the platform manage the certificate and redirect plain HTTP to HTTPS. Then, if you ever move the service to another region or even another provider, you can change the target of the domain and leave the feed address untouched. Use the same canonical address in the link tags of your pages, so tools that discover the feed from a web page find the right one.
A feed service is cheap to run, but cheap is not free of surprises. Costs come from request time, memory, any minimum instances and the outbound data. Compression and a cache in front of the service reduce all of them. Set a maximum number of instances, add a budget alert and check the metrics once a week for the first month. If a single tool fetches the feed far more often than it should, the logs will show its user agent, and you can ask the owner to slow down or put a rate limit in front of the service. For most publishers the monthly cost of a feed service is small compared with the time saved by publishing content from one source of truth.
Use the platform’s logs and metrics to watch request counts, error rates and latency. Add an uptime check that requests the feed and verifies the status and the content type, and an alert for a feed that has not changed in an unusually long time. A feed can be reachable and still wrong: an empty channel, an old date or a broken character are all errors that a simple status check misses. Validate the feed with the W3C Feed Validation Service after each release, and see the feed validation guide for a routine you can repeat.
PostRSS has been publishing RSS and Atom feeds to social networks since 2014. Paste the address of your feed, connect your accounts and choose how each post is built; PostRSS can check the feed as often as every minute and publishes each new item with its real image and link to the networks you select among its 66 supported networks. Because the service answers quickly and carries cache headers, the checks cost almost nothing. Add UTM parameters to the posted links to see which network brings readers. See the PostRSS features page for the options and the pricing page for plan limits.
Cloud Run turns a few dozen lines of code into a dependable RSS feed. Build the XML from stateless data, escape every value, send the RSS content type and cache headers, allow public access, keep the image small, decide on a minimum instance count, protect secrets and map a stable domain. Put a cache in front, monitor the result and validate after every release. Then connect the address to an auto-poster, so each new article reaches your audience on social networks without further work.
Yes. A small container with one route that returns XML with the RSS content type works well, and the service can scale to zero between requests.
Rarely. Most tools wait long enough. Keep the image small, or set a minimum of one instance and add a cache in front if you want consistently fast answers.
For a public feed, yes. If authentication is required, tools receive an error page instead of XML and report an invalid feed.
Map a custom domain to the service, so the address does not change when you redeploy or move regions.
Yes. PostRSS reads any valid RSS or Atom address that is reachable without a login, regardless of where it is hosted.
What changed in the networks, what broke, and how to fix it before it costs you reach.
PostRSS बनाने वाली टीम Internet Solutions की ओर से। हर प्रोडक्ट आपका समय अपने तरीके से बचाता है।