# Vagrant Up Works But Deploying to Droplet Gets Errors **URL:** https://discourse.roots.io/t/vagrant-up-works-but-deploying-to-droplet-gets-errors/21871 **Category:** trellis **Created:** 2021-12-14T02:22:20Z **Posts:** 6 ## Post 1 by @Dan_Randall — 2021-12-14T02:22:20Z Trying to deploy to a staging environment with ./bin/deploy.sh staging ‘[myhost.com](http://myhost.com)’ fails trying to get private packages from packagist (authentication). (vagrant up seems to work.) These same playbooks and associated setup work for my colleagues. If I check auth.json on the droplet (remote VM) the file has no credentials. If I pause the playbook and add a packagist token on the remote server I can avoid the error but the resulting droplet still doesn’t work normally. I have a suspicion that more than just the token is failing to make it in to the environment when I deploy to staging, but the auth errors trying to get to the private repo are where the playbook fails explicitly. I am looking for ideas. I clone the same files and appear to have the same tools/software installed as my coworkers, but my deploys to staging fail. Note that after the deploy fails with the auth errors with repo.packagist, the droplet has no current directory like /srv/www/name/current where I would normally see elements of the install. Any suggests or comments are welcome and appreciated! --- ## Post 2 by @swalkinshaw — 2021-12-14T03:15:57Z :thinking: that’s very odd. If your colleagues can deploy without issue I can’t think of why you couldn’t. Assuming, as you said, that everyone is using the same playbooks from source control. > droplet has no current directory like /srv/www/name/current This should only happen if there’s _never_ been a successful deploy (or someone manually deletes it). If there’s a `current` release, failures would just prevent that symlink from being updated to the new release, and not delete it. --- ## Post 3 by @Dan_Randall — 2021-12-14T03:51:15Z Hey Scott, Thanks a bunch for the reply. I am trying to deploy into a fresh droplet to support user testing. I have been destroying and trying again, so they haven’t had a successfully deploy yet (this is not true of my colleagues systems or production). If I pause the playbook in build-after.yml after task “Setup composer authentications” and go to the droplet and manually add the packagist token to auth.json before I allow it to continue, the errors in “Install Composer dependencies” don’t happen _and current is created_, but the site in the staging droplet still doesn’t come up. Dan --- ## Post 4 by @alwaysblank — 2021-12-14T15:20:49Z You can get Trellis to generate an `auth.json` for you on deploy: [Composer failing due to incorrect GitHub fingerprint - #7 by alwaysblank](https://discourse.roots.io/t/composer-failing-due-to-incorrect-github-fingerprint/21735/7) You mention this is a “fresh droplet”: have you provisioned it? [Trellis: Remote Server Setup | Roots Documentation](https://docs.roots.io/trellis/master/remote-server-setup/#provision) --- ## Post 5 by @Dan_Randall — 2021-12-14T21:47:14Z Hi Ben, Thanks for the help! Your link told me that others had occasionally seen similar issues it really helped knowing I wasn’t on a wild goose chase. Our vault has packagist and github tokens which I can see with ansible-vault view, but my deploys don’t seem to pick them up. My remote auth.json is empty json. I had previously tried adding my packagist token manually to the remote auth.json and that removed errors, but still didn’t result in a working site. After reading your suggestions I transferred my entire local auth.json which included a github token as well as a packagist token and the remote site came up normally. Finally! I really appreciate the help. I don’t know why the tokens aren’t pulled from the vault (they do get pulled successfully for my coworkers), but transferring the auth.json is an easy extra step. --- ## Post 6 by @alwaysblank — 2021-12-14T22:08:20Z Do you have the appropriate user keys? [trellis/users.yml at master · roots/trellis · GitHub](https://github.com/roots/trellis/blob/master/group_vars/all/users.yml) --- ## Post 7 by @system — 2022-01-25T02:23:04Z This topic was automatically closed after 42 days. New replies are no longer allowed.