<p>We use <a href="http://rsync.samba.org/" rel="nofollow">rsync</a>. This can either be run manually with your CLI or you could set up a cron to run it every so often. It's significantly faster than FTP.</p>

CC BY-SA 3.0
2014-07-16T15:28:27.397Z
Which folders do you rsync with?
Jacob Graf
CC BY-SA 3.0
2014-07-16T15:31:58.270Z
This will depend a bit on how your environment structure is setup, but we just do `public/uploads` and then keep all Assets paths to that folder. Those are the only files that change on a remote environment that wouldn't otherwise be in our repo.
Ryan Shrum
CC BY-SA 3.0
2014-07-16T15:36:01.700Z
So each of your developers sync to a central development server?
Jacob Graf
CC BY-SA 3.0
2014-07-16T15:54:11.903Z
Just in terms of the uploads; rsync is run to each dev's local setup. https://www.dropbox.com/s/o7u9w1ft2wi1zw8/rsync.jpg All the other files are handled via Git and go upwards
Ryan Shrum
CC BY-SA 3.0
2014-07-16T15:57:06.743Z
For my own understanding: @RyanShrum When you say "repo", do you mean git repo? Are you excluding these files from your git repo? If so, why? If they were in git repo, couldn't each developer pull them down to respective local dev environments, and then the shared remote dev DB would know about them?
Andrea DeMers
CC BY-SA 3.0
2014-07-16T15:57:07.860Z
Got ya so in order for this to work, an upload must take place on a shared development server and cannot happen from the local environment that's using the shared DB, right?
Jacob Graf
CC BY-SA 3.0
2014-07-16T16:00:15.270Z
@AndreaDeMers - Yes. we've always left upload directories out of our Git repositories, for no other reason than file size.
Ryan Shrum
CC BY-SA 3.0
2014-07-16T16:01:55.750Z
@JacobGraf You are correct, though I presume you could do something similar between the local environments. I assumed that you were dealing with a shared file server when you referenced a shared DB.
Ryan Shrum
CC BY-SA 3.0
2014-07-16T16:42:37.510Z
Thanks for your insight Ryan! Anyone else do anything different?
Jacob Graf
CC BY-SA 3.0
2014-07-16T15:25:11.427Z
2014-07-16T15:25:11.427Z
Ryan Shrum
<p>I think Ryan's solution is the best, but since you're looking for other ways...</p>

<p><a href="http://www.panic.com/transmit/" rel="nofollow noreferrer">Transmit's</a> sync feature works very well for user upload directories. Sync down or sync up as needed. I use this only for user upload directories (for me <code>html/assets</code>). Everything else is handled with Git, similar to the way Ryan described. I also <code>gitignore</code> the user upload directories (seems the wise thing to do).</p>

<p>Here is a screenshot of Transmit's sync dialogue.</p>

<p><img src="https://i.sstatic.net/Om8Di.png" alt="Transmit sync dialogue"></p>

CC BY-SA 3.0
2014-07-16T17:22:50.120Z
2014-07-16T17:22:50.120Z
Alex Kendrick
<p>I just ran across this with a dev enviroment and live enviroment. I ended up setting the asset url as an absolute path pointing to live. So that when entries are created on live, and images are uploaded, dev will then use the urls from live for the images, since I have dev and live both pointing to the same db.</p>

CC BY-SA 3.0
2015-10-30T21:31:10.107Z
2015-10-30T21:31:10.107Z
Bowenac
<p>I am curious how those of you who use a multi-environment development process handle user upload directories? If you use a remote database and one developer uploads some test content, the shared database will think there are files on the other developers machine and they won't be there. This would also show its face if you access a staging server. The database would be out of sync with the upload directory.</p>

<p>Thanks for your input.</p>

CC BY-SA 3.0
2014-07-16T21:37:21.983Z
Thanks for the feedback. I "think" I have found a pretty nifty solution to the problem. I have been using Amazon S3 as my assets source which solves the issue. I was recently thinking about switching back to local storage to see if there would be any performance gains but then I thought about the version control issue I asked about. Is anyone seeing any downsides to using Amazon S3 in this situation? By using that, everybody can upload/download and it all stays in sync with the shared development database.
Jacob Graf
<assets><multi-environment>
Multi-Environment Uploads
# Multi-Environment Uploads

(Asked by: username_0 on 2014-07-16)

I am curious how those of you who use a multi-environment development process handle user upload directories? If you use a remote database and one developer uploads some test content, the shared database will think there are files on the other developers machine and they won't be there. This would also show its face if you access a staging server. The database would be out of sync with the upload directory.

Thanks for your input.

**Tags:** assets, multi-environment
> **Comments:**
> **username_0**: Thanks for the feedback. I "think" I have found a pretty nifty solution to the problem. I have been using Amazon S3 as my assets source which solves the issue. I was recently thinking about switching back to local storage to see if there would be any performance gains but then I thought about the version control issue I asked about. Is anyone seeing any downsides to using Amazon S3 in this situation? By using that, everybody can upload/download and it all stays in sync with the shared development database.  

---

## 3 answers

### Answer by username_1 on 2014-07-16. Score: 3 | Accepted answer

We use [rsync](http://rsync.samba.org/). This can either be run manually with your CLI or you could set up a cron to run it every so often. It's significantly faster than FTP.

> **Comments:**
> **username_0**: Which folders do you rsync with?  
> **username_1**: This will depend a bit on how your environment structure is setup, but we just do `public/uploads` and then keep all Assets paths to that folder. Those are the only files that change on a remote environment that wouldn't otherwise be in our repo.  
> **username_0**: So each of your developers sync to a central development server?  
> **username_1**: Just in terms of the uploads; rsync is run to each dev's local setup. https://www.dropbox.com/s/o7u9w1ft2wi1zw8/rsync.jpg All the other files are handled via Git and go upwards  
> **username_2**: For my own understanding: @RyanShrum When you say "repo", do you mean git repo? Are you excluding these files from your git repo? If so, why? If they were in git repo, couldn't each developer pull them down to respective local dev environments, and then the shared remote dev DB would know about them?  
> **username_0**: Got ya so in order for this to work, an upload must take place on a shared development server and cannot happen from the local environment that's using the shared DB, right?  
> **username_1**: @AndreaDeMers - Yes. we've always left upload directories out of our Git repositories, for no other reason than file size.  
> **username_1**: @JacobGraf You are correct, though I presume you could do something similar between the local environments. I assumed that you were dealing with a shared file server when you referenced a shared DB.  
> **username_0**: Thanks for your insight Ryan! Anyone else do anything different?  

---

### Answer by username_3 on 2014-07-16. Score: 3

I think Ryan's solution is the best, but since you're looking for other ways...

[Transmit's](http://www.panic.com/transmit/) sync feature works very well for user upload directories. Sync down or sync up as needed. I use this only for user upload directories (for me `html/assets`). Everything else is handled with Git, similar to the way Ryan described. I also `gitignore` the user upload directories (seems the wise thing to do).

Here is a screenshot of Transmit's sync dialogue.

![Transmit sync dialogue](https://i.sstatic.net/Om8Di.png)


---

### Answer by username_4 on 2015-10-30. Score: 2

I just ran across this with a dev enviroment and live enviroment. I ended up setting the asset url as an absolute path pointing to live. So that when entries are created on live, and images are uploaded, dev will then use the urls from live for the images, since I have dev and live both pointing to the same db.


---

