Remotely Save for Obsidian: S3 and WebDAV Sync That Costs $0 on R2

I’ve used Remotely Save to sync Obsidian to my phone and iPad since the first week I started using Obsidian. I told it to use Dropbox, it worked, and I didn’t think about it. That’s the greatest praise you can give a sync plugin.

Then I started to write this post and checked the changelog. The latest release is 0.5.25, from October 20, 2024. The last commit to the repo is from November 2024. It has 2.3 million downloads and over 200 open issues. So before we start with buckets and endpoints, just know that you’re putting a two year frozen plugin on your system. I covered the plugin briefly in my guide to syncing an Obsidian vault across devices. This is the long version of the part that guide skipped: pointing it at storage you own.

• Is Remotely Save Dead?
• Why Bring Your Own Bucket
• What It Actually Costs
  • The AWS bill is mostly requests, not storage
• Setting Up Cloudflare R2
• Setting Up AWS S3 Without Handing Over Your Account
• The CORS Step You Can Skip
• WebDAV: Nextcloud, InfiniCLOUD, and Your NAS
• Encryption: RClone Crypt or OpenSSL
• Free vs. PRO, If You’re Picking a Backend Anyway
• Settings That Bite
• Should You Use It?

Is Remotely Save Dead?

I don’t know, and neither does anybody else outside the developer’s head. This much is true as of this writing.

The repo is not archived. No “this is dead now” posts. It installs from the community directory, and it still syncs my vault daily. Obsidian’s plugin API is not the type to break stuff often. So a 2024 plugin works… well… Mostly.

What worries me more is not the code. It’s remotelysave.com that handles PRO tier. “FREE during beta until Jan 1, 2027”. “The price will be set later.” That’s 10 weeks from when this posts.

Unreleased for 2 years plugin, service with a deadline, but no price. Not exactly confidence-inspiring.

I wrote it anyway because it all runs on free tier below. S3, Cloudflare R2, Backblaze B2, MinIO, WebDAV. No account needed at remotelysave.com.

If PRO service disappeared tomorrow, you’re still good. The plugin communicates directly to your bucket. There is no intermediary server in the mix. If you’re going to use a zombie plugin, this is how you should do it.

Why Bring Your Own Bucket

Obsidian Sync is the easy answer and it’s good. But the Standard plan gives you 1GB of storage.

I measured the part of my writing vault that Remotely Save syncs: 9,371 files, 1.62GB. Only 80MB of that is markdown. The rest is images, PDFs, and the junk from years of web clipping. So Standard is already too small for me, and I’d be on Plus.

The BYO storage pitch is:

1. The storage is yours. Your notes live in a bucket you own, in a format you can read without Obsidian.
2. It’s cheap or free. For a normal vault, the bill rounds to zero. I’ll show numbers in a bit.
3. It works everywhere Obsidian does, including iOS, where folder sync is a nightmare. I covered why in the iPhone and iPad sync guide.

Trade off is someone else’s problem becomes your problem. Obsidian Sync has a support team. You have your R2 bucket.

What It Actually Costs

I went through my own vault: 1.62GB, synced from 3 devices.

R2 is the sleeper pick. No egress fees from Cloudflare. All those devices that download your full vault for the first time, that’s egress. 10 free gigabytes is a lot of markdown.

The AWS bill is mostly requests, not storage

AAWS is the weird numbers one. Storing 1.62GB in S3 Standard costs about four cents a month. No big deal.

What costs money is asking the bucket what’s in it. A sync starts by listing the remote files, and S3 bills LIST requests at the same rate as PUT, $0.005 per thousand. A listing returns at most 1,000 objects, so my vault takes about 10 requests just to look. Run auto-sync every five minutes on three devices for eight hours a day and you’re at around 86,000 list requests a month. That’s roughly 43 cents. More than ten times the storage bill, for checking whether anything changed.

Forty-three cents is still nothing. But it’s why people get surprised by S3 bills, and it’s one more reason R2’s flat free tier is the better deal for this.

Setting Up Cloudflare R2

This is the setup I’d pick if I were starting today. Remotely Save’s own R2 tutorial is short, and so is this.

1. Make a Cloudflare account and enable R2. It will probably want a credit card even though you’ll stay in the free tier. Annoying, but normal for cloud storage.
2. Create a bucket. Name it something like obsidian-vault.
3. Create an API token with Object Read & Write permission, scoped to just that bucket. Don’t give it access to everything on your account.
4. Save what it shows you: the access key, the secret key, and the endpoint URL. Cloudflare only shows the secret once.
5. In Obsidian , install Remotely Save (the plugin install walkthrough covers that), open its settings, and pick S3 or compatible as the remote service.
6. Fill in the endpoint, region us-east-1, access key, secret key, and bucket name. R2 doesn’t really use regions, and us-east-1 is what the tutorial says to put there.
7. Turn on Bypass CORS. The tutorial calls this “usually what you want,” and it is.
8. Click Check Connectivity , then run your first sync.

Back up the vault before that first sync. Copy the folder somewhere Remotely Save doesn’t know about. Every sync tool I’ve covered in this series gets the same advice, because the first sync is when you find out you configured something backwards.

The one R2 issue: older versions of the plugin failed the connectivity check even when the settings were right, because Cloudflare doesn’t allow that kind of key to run HeadBucket. Version 0.3.29 switched to ListObjects and fixed it. Since the current version is 0.5.25, this only bites you if you’re running something ancient. If the check fails, look at your keys before you blame Cloudflare.

Setting Up AWS S3 Without Handing Over Your Account

R2 asks for a scoped token and you’re done. AWS makes you build the scope yourself, and this is where it’s easy to get stuck. The easy move is to use your root account’s keys because they’re right there.

Don’t. Those keys can do anything to your entire AWS account, and now they live in a plugin settings file on your phone.

Instead, create an IAM policy that can touch one bucket and nothing else. This is the policy from the plugin’s S3 user policy doc, with my-bucket swapped for your bucket name:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ObsidianObjects",
            "Effect": "Allow",
            "Action": [
                "s3:HeadObject",
                "s3:ListBucket",
                "s3:PutObject",
                "s3:CopyObject",
                "s3:UploadPart",
                "s3:UploadPartCopy",
                "s3:ListMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:CompleteMultipartUpload",
                "s3:ListObjects",
                "s3:ListObjectsV2",
                "s3:ListParts",
                "s3:GetObject",
                "s3:GetObjectAttributes",
                "s3:DeleteObject",
                "s3:DeleteObjects"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket",
                "arn:aws:s3:::my-bucket/*"
            ]
        }
    ]
}

Then:

1. In IAM, create a new user and choose Attach policies directly. Attach the policy above.
2. Open that user, go to Security credentials , and create an access key. If it asks for a use case, pick Other.
3. Put that access key, the secret, your bucket name, and the bucket’s region into Remotely Save.

The doc says that the bucket itself doesn’t need a policy, only the user. It also says “not fully tested,” which is good of them to admit, and a reason to test a sync with a throwaway note first.

The CORS Step You Can Skip

If you’ve read an older Remotely Save guide, you’ve seen a big block of CORS JSON with origins like app://obsidian.md and capacitor://localhost. It used to be the step that broke everybody’s setup.

You probably don’t need it anymore. The plugin’s CORS doc says it’s only required on Obsidian desktop below 0.13.25 or mobile below 1.1.1. Newer Obsidian lets the plugin make requests that don’t go through the browser’s CORS rules, which is what the Bypass CORS toggle is about. Those version numbers are years old. If you are running Obsidian that old, CORS is not your biggest problem.

So if a tutorial sends you into your bucket’s CORS settings, skip it, turn on Bypass CORS, and only come back to it if the connectivity check fails. WebDAV has its own CORS doc with the same desktop and iOS cutoffs, plus one exception: it says Android needs CORS on the WebDAV server at any version, and Nextcloud and ownCloud don’t turn it on by default. If you sync from an Android phone over WebDAV, read that doc before you skip anything.

WebDAV: Nextcloud, InfiniCLOUD, and Your NAS

WebDAV is the other free-tier backend, and it’s the one for people who already run a server or own a NAS. Remotely Save has setup docs for a dozen of them. Here’s the 3 most people will care about:

• Nextcloud. If you already self-host it, this is the obvious pick. Your notes land next to everything else you run.
• Synology NAS. Turn on the WebDAV Server package and point the plugin at it. It’s great at home. Away from home you’ll need a way to reach the NAS, and exposing it to the internet so your phone can sync is something to do only if you understand what you’re letting in.
• InfiniCLOUD (it used to be called TeraCLOUD). A hosted WebDAV service with a free plan that recent listings put at 20GB. The catch is that free accounts can be deleted after two years without a login. A sync plugin that’s working perfectly never makes you log into the website, so put a reminder in your calendar.

Setup is the same every time: pick Webdav in the plugin, enter the server address, username, and password, and check connectivity. The plugin puts your vault in a subfolder named after it, so one WebDAV account can hold several vaults without them stepping on each other.

I’ve never run my vault through WebDAV. I’ve used Dropbox the whole time. So for this section I’m going on the plugin’s docs, not my scars. If you hit something weird with a specific server, the per-server tutorials in the repo’s docs/remote_services/ folder are where to start.

Encryption: RClone Crypt or OpenSSL

If you set a password, Remotely Save encrypts your files on your device before they go up. Leave it blank and your notes sit in the bucket as plain markdown. With your own S3 bucket, plain is defensible. With a third-party WebDAV host, set a password.

You get two formats, and the plugin recommends RClone Crypt. Its own comparison page lays out the difference:

The filename row is the real tradeoff. RClone Crypt encrypts each folder name and filename on its own, so your folder structure survives. Someone with access to the bucket can’t read your note titles, but they can see that you have a folder with 400 things in it, nested three deep. OpenSSL hides the structure too, at the cost of not being able to open your vault with a standard tool.

I’d still take RClone Crypt. Being able to run rclone mount and read my notes without Obsidian is the point of owning the bucket.

Two warnings from that page. First, if you ever switch formats, you have to delete the remote files “manually and fully” so the plugin can re-upload everything. Second, the page says the author “doesn’t have sufficient knowledge to ‘judge’ which one is the better format.” Credit for saying so, and a reminder that this is a hobby project’s encryption, not an audited product. Use a long password. Also, for Dropbox, OneDrive, and WebDAV, the vault’s name itself isn’t encrypted. Don’t name your vault after something you’re hiding.

Free vs. PRO, If You’re Picking a Backend Anyway

The split as of 0.5.x:

Free, no account: S3 and anything S3-compatible (R2, B2, MinIO), Dropbox, WebDAV, OneDrive’s App Folder, and Webdis, which the README calls “mostly experimental.”

PRO, needs a remotelysave.com account: Google Drive, Box, pCloud, Yandex Disk, Koofr, Azure Blob Storage, full OneDrive access, and Smart Conflict.

Smart Conflict is the PRO feature I’d actually miss. On the free tier, the plugin detects a conflict and you pick a rule: keep the newer file or keep the larger one. Whichever loses is gone. Smart Conflict tries to merge two versions of a small markdown file instead, and for anything it can’t merge, it keeps both.

The free list is exactly the backends this post is about. If you choose R2, B2, S3, or WebDAV, the PRO price that gets announced after January 1 doesn’t touch you.

Settings That Bite

Most of these come from the README, which I read properly for the first time while writing this:

• Files starting with . or _ don’t sync by default. If you have an _attachments folder, it isn’t going anywhere. Your .obsidian config folder can sync, but that option is marked experimental.
• Auto-sync only runs while Obsidian is open. It’s an interval timer inside the app. Close the app and nothing syncs. Open it on your phone and nothing is current until the next run, so hit sync by hand before you start writing.
• Errors “fail silently.” That’s the README’s phrase. A broken auto-sync looks exactly like a working one with nothing to sync. Check the last sync time once in a while.
• Big files are slow on mobile. The README flags trouble at 50MB and up. There’s a Skip Large Files setting and a regex filter for paths. Use them before your phone tries to pull down a 300MB PDF over cell data.
• data.json holds your keys. It’s in .obsidian/plugins/remotely-save/, and it has your secret key or tokens in it. The plugin drops a .gitignore into its own folder that excludes it. And one I did to myself. My laptops sync the vault through the Dropbox app, and my mobile devices sync it through Remotely Save. That plugin folder sits inside the vault, so Dropbox syncs each laptop’s copy of the plugin’s settings file. When I went looking just now, I found this in it:

data (Stephan Miller's conflicted copy 2025-12-14) (Stephan Miller's conflicted copy 2025-12-14).json

A conflicted copy of a conflicted copy. That’s my own rule from the pillar, “don’t run two sync systems on one vault,” broken by me in my own vault, and it’s been there since December. It’s harmless here, since the plugin ignores those files. But it’s the kind of mess you get when two tools both think they’re in charge.

Should You Use It?

If you want Obsidian on every device without a subscription, and you’re fine owning a bucket, yes. With a caveat I didn’t have to write a year ago.

Remotely Save has done its job for my phone and iPad for years and it’s still doing it today. R2 makes it free for most vaults. AWS makes it cost pocket change, mostly for listing files. WebDAV is free if you already run the server. Encryption is there, with the author’s own disclaimer attached.

But it hasn’t had a release since October 2024, and nobody is telling us whether that’s a pause or the end. So set it up the way that survives the plugin going away: a free-tier backend, RClone Crypt if you encrypt, and a backup that isn’t the sync target. If the plugin stops working someday, your notes are still in a bucket you own, readable with rclone. That’s a better exit than most sync tools give you.

If you’d rather someone else worry about all this, Dropbox is the simplest Remotely Save backend, and Syncthing skips the cloud entirely. Me, I’m keeping my setup. I should probably delete that conflicted copy, too.