Is it safe to run apt-get update -y through cron on a production server?

  • 4
    Are you thinking about apt-get upgrade -y rather than update? Is there any -y flag for update?
    – KajMagnus
    Sep 22, 2013 at 12:48

11 Answers 11


It may be safe—or, more accurately, the level of risk may be within your range of comfort. The level of acceptable risk will depend on several factors.

Do you have a good backup system that will allow you to quickly revert if something breaks?

Are you forwarding server logs off to a remote system so that if the box goes belly up you will still know what happened?

Are you willing to accept the possibility that something may break and you may have to do a quick restore/revert on the system if something fails?

Have you manually compiled anything on your own, or did absolutely everything installed on your system come from the official repositories? If you installed something locally, there is a chance that an upstream change may break your local maintained/installed software.

What is the role of this system? Is it something that would barely be missed if it died (e.g. a secondary DNS server) or is it the core piece of your infrastructure (e.g. LDAP server or primary file server).

Do you want to set this up because nobody responsible for the server has the time to maintain the security patches? The potential risk of being compromised by a un-patched vulnerability may be higher then the potential for a bad update.

If you really do think you want to do this, I suggest you use one of the tools that already are out there for this purpose like cron-apt. They have some logic to be safer then just a blind apt-get -y update.

  • 2
    You're thinking about apt-get upgrade, not apt-get update, right?
    – KajMagnus
    Sep 22, 2013 at 12:47
  • Yes, he is. With apt-get update, it's rather hard to break anything.
    – Olli
    Feb 2, 2014 at 20:47
  • 1
    It is NOT safe.
    – marcinn
    Mar 1, 2017 at 12:04

Yes, as long as you are talking about update and not upgrade. Apt will even do it for you if you put the line:

APT::Periodic::Update-Package-Lists "1";

in a file under /etc/apt/apt.conf.d/


It is generally safe, but I wouldn't recommend it for a simple reason:

  • You lose a known state.

In production environment, you need to know exactly what's on it, or what's supposed to be on it, and be able to reproduce that state with ease.

Any changes should be done via Change Management process, where the company is fully aware of what they are getting into, so they can later analyze what went wrong and so forth.

Nightly updates makes this kind of analysis impossible, or harder to do.


I might do that on stable, or on Ubuntu, but not on an unstable branch, or even the testing branch.

Though, when I put my sysadmin hat on, I believe that I should be manually applying all updates, so that I can maintain consistency between servers -- and also so that, if one day a service breaks, I know when I last updated that service. That's something I might not check if updates were proceeding automatically.


We use stable and schedule apt-get upgrade for Tuesday evening on most of our Debian systems (coincides with our Microsoft "patch tuesday" updates). It works out well. We also have all upgrade events logged to Nagios, so we can see a history of when upgrades were last performed on any server.


When you specify this is a "production" server, does that mean there are development and test servers as well? If so, the patches should be tested on those systems before being installed on the production box.

I wouldn't do it. Bad patches do happen and I wouldn't want a system failing in the middle of the night or while I was otherwise unavailable. They should be pushed in a maintenance window when an administrator is available to monitor the update.


I remember doing that in a previous job; I ended up with problems on the production server because an update rewrote a config file automatically.

Therefore, I would advise you to supervise updates.

  • apt-get upgrade may broke something due to autorestarting services. Obviously, it is NOT safe. Your answer should be accepted instead.
    – marcinn
    Mar 1, 2017 at 12:03

If the alternative is irregularly applying updates, you don't actively follow security updates, and you are running a vanilla stable Lenny, then auto-updating probably increase the security of your machine, since you will update known security holes faster.


Ubuntu Server has a package that will allow it to auto update security updates. It allows you to blacklist certain apps as well. It also talks about apticron which will email you when there are updates available for your server.

You can find out more about it at the following pages depending on which version of Ubuntu Server you're running.

EDIT: Assuming you're running Ubuntu. Although I would bet the same packages and solution is available on Debian.


Take a look at cron-apt. It only downloads the lists and package files by default, but you can tune it to send mails, or even upgrade the system.


This depends on your infrastructure. If I have a single machine, then usually i review the updates, and see what i need or what i can avoid. If i'm using a cluster, I sometime roll out the changes on one machine, and see how they go, and then roll it out to the other machines if everything seems okay.

Database upgrades I always keep a close eye on.

If you have a file system that support snap shotting, can be really useful to snapshot the system, apply updates, and then have the option of rolling back the changes if something goes horribly wrong.

Try to find out why a package is being upgraded? is it bug fix? security fix? is it is a local command or a remote network service?. Has the software been tested with the new updates?

Kernel updates should be approached with more caution. Try and find out why the kernel is being upgraded? Do you really need those changes? will it effect your application. Do i need to apply this for security?

9 times out of 10 software updates will go smoothly, but it's those rare times that it's leaves you machine as a pile of junk, have a rollback or system recovery plan in place.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .