The player looks right. The waveform draws, the play button glows, the track starts on your laptop.
Then someone opens the page on an iPhone and the scrubber refuses to move. A producer shares the link on a Friday night and the previews start buffering. Three months later a storage bill arrives for a site that sells nothing yet.
None of that is a player problem. It is a hosting problem, and on an audio-first site it is the least visible decision with the most visible consequences.
We have written about which codec to pick and how to keep files light. This is the step in between: once the file exists, where it lives, and what that location has to do for the player to behave.
What an audio host actually has to do
A file URL is not enough. For audio on the web, the server behind that URL has four jobs.
Answer range requests. Browsers rarely download a track in one go. They ask for a slice of bytes, and the server answers with 206 Partial Content. That is what makes seeking work, and it is what lets playback start before the file has finished downloading. Safari is the strict one here: its media stack expects range support, so a server that ignores the Range header produces exactly the frozen scrubber described above, on iPhone, where almost every browser runs on Safari's engine.
Send the right content type. audio/mpeg for MP3, audio/mp4 for AAC in an M4A container, audio/ogg or audio/webm for Opus depending on the wrapper. A file served as application/octet-stream may play in one browser and be refused by another.
Be cacheable. A preview that a hundred visitors play should leave the origin once, not a hundred times. That depends on Cache-Control headers and on whether a CDN sits in front.
Allow your code to read it, when your code needs to. A plain <audio> element can play a file from any domain. The moment your code touches the samples, the rules change. Fetching a file to decode it with the Web Audio API, or routing an <audio> element into an analyser to draw a live waveform, requires the host to send an Access-Control-Allow-Origin header. Without it, the fetch fails, or the analyser receives silence and your visualiser flatlines with no error worth reading.
Every hosting option below is a trade on those four jobs.
Option 1: upload the file to Framer
The simplest path is the one already in the editor. Upload the audio as an asset or into a CMS file field, and Framer serves it from its own content domain.
For a small site this is often the right answer. A sound logo, a handful of previews, a background loop on a landing page. There is nothing to configure, nothing to pay for separately, and the file travels with the project.
The limits show up with scale and with code.
Management is one file at a time. Forty beats with two versions each is eighty uploads, by hand, inside the CMS.
Replacing a file changes its URL. Anything that pointed at the old file, a newsletter, a pinned post, a press kit, still points at the old one.
You do not control the headers. If a future feature needs CORS or a specific cache policy, you cannot set it.
None of this means Framer hosting fails. It means you should test it against the four jobs before you trust it with a catalog, using the two-minute check at the end of this note.
Option 2: object storage behind a CDN
Once audio is a catalog rather than a detail, it belongs in object storage: a bucket you control, with a CDN in front and your own subdomain on top, something like audio.yourdomain.com.
The usual candidates are Cloudflare R2, Amazon S3 with CloudFront, and dedicated storage CDNs such as Bunny. They all do the four jobs. The difference that matters for audio is how they bill reads.
Audio is heavy and read-heavy. A three-minute MP3 preview at 160 kbps weighs around 3.6 MB. Ten thousand plays is roughly 36 GB leaving your storage. Most clouds bill that outbound traffic per gigabyte, so a track that spreads on social media turns directly into a cost.
That is why Cloudflare R2 is our default recommendation for audio. R2 charges for storage and operations but not for egress. The free allowance covers 10 GB of storage, a million write operations and ten million read operations a month, which is a large producer catalog at preview quality. Paid storage beyond that is $0.015 per GB-month.
Three settings decide whether it behaves:
Use a custom domain, not the development URL. R2 hands every public bucket a default
r2.devaddress. It is meant for testing and is rate-limited. Connect a subdomain of your own site so the CDN cache applies.Set CORS on the bucket the day you create it, allowing your site's origin for
GETandHEAD. You will need it the first time someone asks for a live waveform.Set a long cache lifetime on the files and never overwrite them in place. More on that below.
The cost of this option is setup: a bucket, a DNS record, a CORS rule. Half an hour once, and then every track you add is a drag and drop.
Option 3: embeds from streaming platforms
SoundCloud, YouTube and Bandcamp will host audio for free, and their embeds are one paste away.
They are also someone else's player. Their branding, their colours, their related tracks at the end, their cookies, their idea of what happens when a visitor clicks play. A portfolio player that converts is a design decision, and an embed takes that decision away from you. It also cannot persist across pages the way a player you own can, which is the whole point of keeping audio playing while visitors move through a site.
Embeds are fine for discovery: a link back to where your followers already are. They are the wrong foundation for a player you designed.
What not to use: share links
Google Drive and Dropbox links look like file URLs. They are not. They point at pages built for a person to download a document, with redirects, virus-scan interstitials on larger files, and usage limits that are not documented for audio streaming.
They tend to work in testing, because you are the only listener. They fail on the day you need them to work, because that is the day many people press play at once. Keep share links for sending stems to a collaborator, never for a public player.
If Cloudflare sits in front of your site
Many Framer sites, including ours, run behind Cloudflare for redirects, headers and analytics. That adds one trap worth knowing about.
Cloudflare caches by file extension, not by content type, and its default list is narrower than an audio catalog. MP3, OGG and FLAC are on it. M4A, AAC, Opus and WAV are not. If you serve Opus files from a domain proxied by Cloudflare, every play goes back to the origin unless you add a Cache Rule for those extensions.
The fix takes two minutes in the dashboard: one Cache Rule matching your audio path or your audio subdomain, set to eligible for cache, with an edge lifetime of a month or more. Range requests are then answered from the edge, so a seek does not travel back to storage either.
Name files like they will never change
Audio files are the easiest assets on a site to cache aggressively, because a recording does not change. A new master is a new file.
So treat the URL as permanent:
Put a version in the file name:
night-drive-v2.mp3, notnight-drive.mp3overwritten.Serve it with a long cache lifetime. A year is reasonable for a file that never changes.
Point the CMS at the new file when a new version ships, and leave the old one in place until nothing links to it.
Overwriting a file in place is how a client hears the old mix after you shipped the new one. Their browser cached the URL, and the URL did not change.
If you sell a template that plays audio
Templates add one more owner to the problem. A buyer duplicates your project, and every demo track in it still points at the URL you chose.
If the demo audio lives in your bucket, you are now hosting it for every buyer who has not replaced it yet, on a budget you never planned. If you move or delete it, their preview goes silent, and they find out from a visitor.
Two habits prevent that. Ship demo audio uploaded inside the Framer project, so it travels with each copy. And make replacing it the first step of the setup guide, with a line on where to host a real catalog. Changing the demo host later is an update that reaches only new buyers, which is exactly the trap we described in shipping a template update without breaking your buyers' sites.
The two-minute check before you trust a host
Upload one real file. Then run two requests against its public URL from a terminal.
Read the headers against this list:
Accept-Ranges: byteson the first request, and206 Partial Contentwith aContent-Rangeheader on the second. If the second returns200, seeking will break in Safari.Content-Typematches the format:audio/mpeg,audio/mp4,audio/oggoraudio/webm.Cache-Controlhas a longmax-age, and a cache status header from the CDN reports a hit on the second or third request.Access-Control-Allow-Originincludes your site, if any code reads the audio. Add-H "Origin: https://yourdomain.com"to the request to see it.
Then do the human test: open the page on an iPhone, press play, and drag the scrubber to the last ten seconds. If it jumps and plays, the host is doing its job.
Frequently asked questions
Can I host audio files directly in Framer?
Yes. Uploading audio as an asset or into a CMS file field works well for a sound logo, a few previews or a background loop. For a large catalog, or for features that need CORS such as live waveforms, object storage on your own subdomain gives you control over headers, caching and URLs.
Why does seeking not work in my audio player on iPhone?
Usually because the server does not answer HTTP range requests. Safari expects a 206 Partial Content response when it asks for part of a file. Test the URL with a Range header and check the status code.
What is the cheapest way to host a music catalog for a website?
For read-heavy audio, the bill is driven by outbound traffic rather than storage. Storage without egress fees, such as Cloudflare R2, keeps the cost of a popular track close to zero within its free allowance.
Takeaway
Where a file lives decides whether it starts fast, seeks cleanly, can be read by your code, and survives a busy night.
Framer hosting is enough for a few sounds. A catalog belongs in object storage on your own subdomain, with CORS set and a long cache. Embeds are for discovery, share links are for collaborators, and every audio URL should be treated as permanent. Run the two-minute check before you trust any of them.
If you want to hear a player designed around audio from the start, VOLTS is on the Framer Marketplace. And if your brand needs sound worth hosting in the first place, start the conversation about your sonic identity.
