Vagrant for Local Development

Skip to first unread message

Jan 7, 2019, 1:54:22 PM1/7/19
to AtoM Users

After having a hard time installing AtoM for Mac by translating the Linux instructions, I ended up using vagrant option and I want to make sure that the path that I'm on is correct. In the documentation it says not to use vagrant for production.. does that applies to my case:

Using the archive for a lab at a university and the university will ultimately make it public. Currently AtoM is hosted on a local machine running vagrant and through port forwarding made accessible to other computers on the same network. After they have populated the database I want to backup and migrate the archive on the public server for which the university will take care of with no problem, so does this count as production? Are we expected to run into errors using Vagrant to build up the archives locally while periodically backing up and when ready, migrate the archives on the public server? I really appreciate if you can clear that up. 

The one problem that has already come up is facing the 500 internal server error when creating sub-folders, but sometimes it works other times it doesn't which makes me think I need to increase the default PHP memory limit. If you have any suggestions how to fix that I would also really appreciate it.

Thank you for your time.


Dan Gillean

Jan 8, 2019, 11:01:29 AM1/8/19
to ICA-AtoM Users
Hi Nima, 

I will start with some general points on why we don't recommend using the AtoM Vagrant box in production: 

First, the box has not been scaled with enough resources for production level use - the amount of memory, disk space, and CPUs assigned to the virtual appliance are limited. However, these are things you can potentially modify. 

Second, Virtualbox is what is known as a Type-2 hypervisor, and it is designed primarily for "workstation virtualization" - that is Desktop virtualization, which requires a full operating system installed below it. Other virtualization tools such as VMWare ESX/ESXi or Xen are what are known as Type-1 or "bare metal" hypervisors - these run directly on the host hardware, and are tiny operating systems designed only to run VMs and as such, have a smaller footprint. While desktop virtualization does technically have everything you need for virtualization just like a Type-1 hypervisor, a lot more system resources are consumed maintaining the desktop environment and other applications, tools, etc. included in the image, leaving less available for AtoM. I've also read that Virtualbox's networking speed can be slow, and that long-time high performance requires much more host RAM then normal usage would. 

Overall, remember that AtoM is intended to be installed on a server (which is likely why you had issues translating the instructions and installing on a Mac computer) - if you are installing this on a desktop (even if it is virtualized), then it will likely not have the stability, persistence, and scalability to maintain sustained use in production! It can be done, but it is not recommended! 

In your particular case:

It sounds like you want to use the Vagrant box for local data entry, and then you will extract a sqldump of the data (and the uploads directory for any uploaded digital objects) and migrate those to an actual server installation for public access - is this correct?

If so, this is certainly better than trying to simply spin up the Vagrant box and use it for ongoing public access. However, I don't believe we've ever tested using a Vagrant image across multiple machines via port forwarding on a network. I strongly recommend that you create some kind of cron job to regularly back up the database and uploads directory as you do this, so if the Vagrant box crashes, you don't lose all of your work! 

As for the 500 errors: 

The first thing I always recommend is to take a look at the Nginx error logs for more information on the nature of the error. See: 
If you're not sure what the error messages mean and can't find related posts in this forum, feel free to post the message here and we'll do what we can to help troubleshoot. That said, your idea of increasing the PHP execution limits is a good one - we have some further information on doing so here: 
You might also want to take a look at the Troubleshooting page we've added to the 2.5 documentation for ideas - they should all apply to 2.4.x as well: 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit
Reply all
Reply to author
0 new messages