Storage Configuration

TrendRadar automatically picks a suitable storage backend based on how you deploy it. In most cases you don't need to configure anything manually — only GitHub Actions deployments require additional cloud storage setup.

Automatic storage backend selection

Deployment environment	Storage location	Description
Docker / local deployment	Local disk	Data is stored in the output/ directory — works out of the box
GitHub Actions	Cloud storage	The Actions runtime is destroyed after each run, so you must configure cloud storage to persist data

Local storage (SQLite)

Docker and local deployments use local SQLite storage by default. Data is saved in the output/ directory, with no additional configuration required.

output directory structure

The files in the output/ directory serve different purposes:

SQLite database: stores news data, ranking trajectories, RSS entries, AI analysis results, and other core runtime data
HTML reports: visual report files used for email push and web viewing
TXT snapshots: plain-text data snapshots used for debugging and troubleshooting

When this applies

If you deploy TrendRadar with Docker or locally, data is saved to local disk automatically, and you can skip this part. The cloud storage configuration below applies only to GitHub Actions users.

Remote S3 storage (GitHub Actions users)

The GitHub Actions runtime is destroyed after each run, so you need to configure S3-compatible cloud storage to persist data. We recommend Cloudflare R2 — its free tier is more than enough.

Secrets to configure

In your GitHub repository, go to Settings > Secrets and variables > Actions, and add the following Secrets:

Secret name	Value to enter	Required	Description
`STORAGE_BACKEND`	remote	Required	Storage backend type — just set it to remote
`S3_BUCKET_NAME`	your bucket name	Required	For example, trendradar-data
`S3_ACCESS_KEY_ID`	your Access Key ID	Required	Obtained when you create the API Token
`S3_SECRET_ACCESS_KEY`	your Secret Access Key	Required	Obtained when you create the API Token (shown only once)
`S3_ENDPOINT_URL`	your R2 endpoint URL	Required	Format: https://[account-id].r2.cloudflarestorage.com
`S3_REGION`	auto	Optional	Optional; defaults to "auto" and usually needs no change

Cloudflare R2 setup guide

About R2 charges

Cloudflare R2 requires you to add a payment method (for identity verification only — you won't be charged). It supports dual-currency credit cards or PayPal. R2's free tier provides 10GB of storage per month, which is more than enough for the TrendRadar project.

Create a bucket

Click Overview > Create Bucket, enter a bucket name (for example, trendradar-data), then click create.

Get the endpoint URL

Go back to the Overview page, scroll down to the Account Details section, and find the S3 API address. This address is your S3_ENDPOINT_URL:

https://[your-account-id].r2.cloudflarestorage.com

Create an API Token

In the Account Details area, click Manage (R2 API Tokens) to open the token management page. Click Create Account API Token:

Give the token a name (for example, trendradar)
Permissions: Admin Read and Write
Specify bucket: select the bucket you just created
Click Create

Save the keys

Copy and store them safely right away

After creation, the page shows your Access Key ID and Secret Access Key. These two values are shown only once at creation time and cannot be viewed again after you close the page. If you forget to save them, your only option is to delete the old token and create a new one.

Other S3-compatible providers

In addition to Cloudflare R2, TrendRadar supports other S3-compatible storage services. Below are the endpoint URL formats for common providers:

Provider	S3_ENDPOINT_URL format	Notes
Cloudflare R2	`https://<account-id>.r2.cloudflarestorage.com`	Recommended; generous free tier
Alibaba Cloud OSS	`https://oss-cn-<region>.aliyuncs.com`	Replace <region> with the actual region, e.g. hangzhou, shanghai
Tencent Cloud COS	`https://cos.ap-<region>.myqcloud.com`	Replace <region> with the actual region, e.g. guangzhou, beijing
AWS S3	`https://s3.<region>.amazonaws.com`	Replace <region> with the actual region, e.g. us-east-1

Data retention policy

You can configure how many days to keep local and cloud data in config/config.yaml:

storage:
  local:
    retention_days: 0     # Retention days (default 0, i.e. keep forever. Set to 30 to keep only the last 30 days)
  remote:
    retention_days: 0     # Retention days (default 0, i.e. keep forever)

About the retention policy

Data older than the retention period is cleaned up automatically on the next run. If you want to keep all data forever, set retention_days to 0 (this is also the default). For cloud storage, set the retention days sensibly based on your free tier to avoid exceeding the storage limit.

Data pull (MCP Server scenario)

If you use the MCP Server to interact with remote data locally, you can configure automatic data sync from remote to local on startup:

storage:
  pull:
    enabled: false    # Enable auto-pull on startup (true=enable, false=disable)
    days: 7           # Pull data from the last N days

Use case

This feature is mainly for the MCP Server scenario: remote data is automatically pulled to local on startup for local analysis and queries. Disabled by default — enable it as needed.

Timezone settings

Data timestamps depend on the timezone setting. You can adjust the timezone in config/config.yaml:

app:
  timezone: "Asia/Shanghai"  # China time by default

If you use it in another timezone, just change it to the corresponding timezone identifier (for example, America/New_York, Europe/London, etc.).