Extending TTL for Cloud Files CDN Users

Our users have spoken and we have heard loud and clear! We have extended our limits for TTL (Time to Live) for objects on the content delivery network (CDN).  We have moved our limit up from 72 hours to 50 years.

TTL is a limit that you can set on how long you would like your CDN content to “live” on the CDN edge servers.  Once your TTL expires, the edge server checks back with the origin for a new copy of your object.  If your data rarely changes, you can set a longer TTL so the CDN edge server won’t check back with the origin as often resulting in faster response times for your end users.

That being said, the CDN’s edge servers always operate on the logic that the most popular content will stay cached.  That means if your content is less popular, but you have set a 50 year TTL, it won’t necessarily be 50 years before the edge server has to come back to the origin in Cloud Files for your object.

Simply think of TTL as the longest possible time that your content will go without being updated or requested again from the origin.

While we are changing our upper limits, we will still keep our default of a 72 hour TTL.  That means that if you take no action, your set up will remain exactly as it is today.  If you are using our API, you can now set your TTL anywhere from 15 minutes to 50 years, with increments as low as seconds (e.g. TTL = 26 minutes, 30 seconds).  This feature is coming soon within our Cloud Control Panel and will allow users to set their TTL up to 50 years, in hourly increments.

If you have any questions, comments, or concerns about this feature, please let us know.

Rack Blogger is our catchall blog byline, subbed in when a Racker author moves on, or used when we publish a guest post. You can email Rack Blogger at blog@rackspace.com.


  1. Great news – I just signed up and my first thought was “what the hell, 72hrs max? I’m outta here”.

    Any idea when it’ll be available in the control panel, as I’ve not delved into the API yet?

  2. Great to hear that you are both excited about our news!

    Seb- We’re working on the Control Panel integration, but we’re not close enough for me to give exact dates yet. I’ll update this blog post as soon as we roll it out.

  3. I have to admit I’m still not entirely getting this concept. As I understand it:

    1. Files are uploaded to Cloud Files’ central server(s)
    2. If someone accesses my file from Amsterdam, the closest edge server to that person will get the file from the central server and then server it to the user
    3. For 72 hours by default the edge server will serve the file if someone accesses it from the same location
    3. After 72 hours both the edge servers will scrap their versions of the file and re-download it from the central server(s) WHEN ACCESSED

    Anyone know what kind of speed we’re looking at for someone to get a file via the edge server when it’s not already cached on the edge server? Is it still quicker than someone accessing it directly from the original web server (assuming both Rackspace’s central server and my web server are in London for example)?

  4. […] uploads so now companies can store videos, HD movies, very large backup files, etc. •    Extended TTL– TTL or Time to Live has increased from 72 hours to 50 […]

  5. Being able to increase the TTL is good and all, and I appreciate that. However, I don’t really think this fixes many of the potential issues regarding Expires and Cache-Control headers…

    Example scenario:

    I have site.css in Cloud Files,
    I want it to have a far future expiry so people don’t need to request it often,
    so I update the TTL to something longish, say one year.

    Then one day I need to update the site.css, so I upload and overwrite site.css with my updated file.
    Then I need to force browsers to request the file even if they have it in their caches, so I do (as many people do) and append a version number to the end of the url, eg: site.css?v=2

    Now with the updated file uploaded, and my css url modified browsers should request the new file!

    BUT, the TTL I set in the beginning doesn’t just set the Expires headers it also sets the actual TTL for the edge servers, so forcing the browser to get the latest version of a file will only get the latest version on the edge server, not the actual updated file in Cloud Files.. that won’t happen until the edge servers update (ie. a year later, or something).

    TTL is good and all for the edge server’s own use, but the Expires and Cache-Control headers need to be adjustable independently from the TTL.

    Hopefully there are plans to remedy this, it’s a fairly significant issue in my view.

  6. “This feature is coming soon within our Cloud Control Panel and will allow users to set their TTL up to 50 years, in hourly increments.”

    Can you define “soon”? This was written almost five months ago…

  7. Hurry Up!

    I have had a running support ticket open with this for over 10 days. Bugs me that my managed hosting team doesn’t have a definitive answer on this yet.

    Frenky’s article is certainly promising, but for low level developers it really deserves more clarity.

    Again I will say it Hurry Up!

  8. Also looking to get an update on this. I talked to the support staff just now and he told me to go read the API guides to set the TTL time for longer than 72 hours. So much for a company that prides itself in customer service.

  9. After 1 year … still nothing, TTL remains at 72 hours in Control Panel. The “Fanatic Support” “heard loud and clear” and this was all. Probably, this will never change, because with a TTL of 50 years … RackSpace will earn less money than with 72 hours.

  10. almost a year since this blog post and still it’s not possible to set a TTL higher than 72 hours via the control panel – what’s going on??

    megan @ rackspace please give us an update!

    i’m not clever enough to use the API to do this!!

  11. I would like to add my name to the list of people who think it’s totally weak that we cannot set the TTL past 72 hours using the web, nor with the iPhone app, a year after Rackspace promised this feature was “coming soon”. HEAR US RACKSPACE!!

  12. Does someone have a video of how to do this. I wouldn’t know the first thing about using API. Or has someone created a webpage where you can put in your API key and set the TTL from there. That would be cool!!

  13. All-
    I sincerely apologize that it took us so long to get this feature put into the control panel. However, I am happy to inform you that users can now set their TTL in the control panel up to 50 years. Let me know if you have any questions.

  14. For me the issue is on the lower end of TTL. When a user uploads a new version of an asset, they expect to be able to download the result immediately as I can provide with Amazon S3. I’ve had to abandon Cloud Files for this reason, however given Amazon’s outage record (west coast is down today) I would love to come back… The edge purge seems like a reasonable start but word on the street is there is a 25 request per day (not going to work for me) and still some lag time. What are the chances you’ll ofter a more realtime solution in the future?


Please enter your comment!
Please enter your name here