One codebase, two different deployment results?


We worked with a developer previously to build our website which is online here:

Unfortunately, we lost contact with the previous developer and the Netlify site was set up in his Netlify account. We are able to update it by pushing changes to the GitHub repo, but we’ve not got any way to get access to create webooks for it (so that changes from our CMS can be automatically pushed live).

As such, we’ve hired a new developer who has set the website up in our Netlify account, it’s online here:

We’ve identified an issue with the projects page.

The projects page on the old site (here) appears to be working as expected. However on the new site (here) there is an issue with the keen slider package which means that the slides aren’t rendered properly when you click a link directly to that page (although when you use the menu bar to navigate away from and then back to the page, that issue corrects.

Since both sites are being generated from the same codebase, I’ve no idea why there is this difference. Perhaps it could be something to do with the settings? I’m wondering whether anyone has encountered this issue before and, if so, could direct me towards a solution?


Bumping this up as I’ve still not got an answer to this question.


hi there, welcome -

so, looking at this, chorus-app is linked to the github repo and the choroslondon site is linked to the github repo

both have had recent deploys, but it looks like the choroslondon site has had a newer deploy, maybe about half an hour or so ago. so far so good.

but the sentiment that both sites are coming from the “same” codebase isn’t correct, as they are linked to different repos.

i have no insight into how the copy repo was generated :thinking: but even if the html pages or whatever content you have or building (as i can’t see either repo’s contents, i’m not sure how the end result is coming about) but there can obviously be major differences from repo to repo even if the content is the same, that is, you can have different dependencies listed out in a package.json, using different libraries, different internal settings set through our UI etc, you get the picture - bottom line is, there must, logically, be some difference between the two.

Not sure that is super helpful, but our hands are little bit tied in the sense that our robots really just deploy what they are asked to! :slight_smile:

oh and for the record, it may take us a few days to respond to post in the forums for free customers, but we do try and get to everyone in a timely fashion - there are only two dedicated forums people and a small team of support engineers for millions of sites worldwide. we promise we will get to everyone as quickly as we can! : )

1 Like

Hi Perry

Thanks very much for getting back to me with this.

The repos that you’ve linked are actually the same repo. If you click both of the urls, you’ll notice that they both redirect back to

I believe the reason for the difference you’re seeing on your side (i.e. the fact that one has the link and the other has the link is because Michael built the first site ( and set up the build from the repo when it was under his GitHub account initially, before transferring the GitHub repo over to our GitHub user/account.

I set up the Netlify-Github repo link on the version of the site yesterday when the repo was located under the ChorusAgency user/account.

The reason for the more recent deploy on the choruslondon version is I triggered the webhook that is specific to this site to make a change to the content based on a change in our CMS. This triggering of the webhook for only choruslondon (and not chorus-app) has taken them out of sync, but otherwise they’d be identical.

Changes made to the repo at are triggering rebuilds on both versions of the site too, which you’d expect not to happen if they were different repos.

Hopefully this is clear and we can look into this further?

Also apologies for prompting you so quickly, I was unaware of your turnaround time and was worried this might have been missed since it was quite far down on the page.



hi there,

here is what i can see when i look at some of your settings with my Special Powers:


i don’t think i see what you are describing here:

"I believe the reason for the difference you’re seeing on your side (i.e. the fact that one has the link and the other has the link is because Michael built the first site ( and set up the build from the repo when it was under his GitHub account initially, before transferring the GitHub repo over to our GitHub user/account."

poking a little further, (with some things obscured for michaelpumo’s privacy, who has a few other sites in their account)

the ChorusLondon account only shows one site.

it seems that the site you are referring to is very much still in the MichaelPumo account. Ergo, I feel pretty sure these are two sites in two teams linked from two different repos. :thinking:

i still believe the problem stems from there being two repos that have subtle differences in some way - as opposed to Netlify deploying the same repo in different ways to different results.

any thoughts?

Hi Perry

Thanks for getting back to me.

I tried clicking on in incognito mode so I could see what you’d see, but realised you’ll not actually see the redirect as the repo is private.

Here is a loom video proving that the link to redirects to and is thus the same repo - Loom | Free Screen & Video Recording Software

Hopefully that helps? Let me know if you need anything else.

hey there, thanks for that video! that is illuminating indeed.

i am going to ask someone else to take over who might be able to explain what exactly is happening here -

we’ll get to the bottom of this somehow, but there may be a bit of a wait until someone has the time to dif in here. thanks for your patience. :slight_smile: :netliheart:

one more question before i let someone else dig in:

how did you set up that repo-to-repo redirect? :thinking:

my current hunch being that a browser might behave different than our builder robots. i am wondering whether they are not respecting the redirect for whatever reason.

just a speculation at this point, but that would explain things.

also, i unlisted this thread for a bit more privacy, so no one can see it who hasn’t got the direct URL and it doesnt show in a search.

Hi Perry

Thanks for getting back to me.

We’ve not set up the redirect from our end, can only assume this is standard behaviour for GitHub when a repo is transferred from one user to another?

Hopefully we can get to the bottom of it.

I’m wondering whether it would be possible to transfer the version under Michael’s Netlify account to our account? This would give us the version that’s working as it should, and therefore negate the need to look any further into the issue (as this would effectively give us a resolution).

Obviously I understand if this is not possible since you’d probably need Michael’s authorisation. Perhaps it would be possible for you guys to contact him? He has not responded to us for many weeks now.

If this is not possible, it would be good if we could at least get his version deleted (to avoid dupe content issues with Google search)? Again, totally understand if this is not possible, given that it’s another users account we’re speaking about here essentially.

This is all a side tangent really away from the main issue, so no worries if you can’t do anything about the version under Michael’s account, we’ll just concentrate on hopefully fixing the one under our account.


hey there,

i had a chance to speak with another support engineer about this, and he confirmed my initial hunch that while indeed the repo may be the same one, there is likely some setting in the UI (and the toml file that those settings generate) that is different from site to site. This would mean that the sites are identical in content, but not necessarily the same in how they are displayed, as these settings are not saved or coming from the git repo.

here is one thing we found that could be the culprit:

> Site.find_by_subdomain("choruslondon").repo.node_version
> Site.find_by_subdomain("chorus-app").repo.node_version

(hats some output from our internal console)

it could be something else, but i would try making both node versions the same. If it works better on the older version, than thats the one you should enforce for the short term,. that said, version 12 is pretty old and you’ll want to get things working on a newer version for security and performance reasons for sure.

info on that here:

more general info here:

your secondary issue with having two sites is something we can address after we get them both working the same. we’ll need to get you talking to a support engineer and do some verifications and lever pulling - as you mentioned, we don’t just delete sites for obvious reasons, but we can see if we can help you out.

let me know if this fix, setting the node versions, works.

Hi Perry

I’d thought the Node version number could have been an issue previously, however the toml file was setting the Node version to 14 so I’m surprised to see this discrepancy.

I’ve removed the version number from the toml file and set a NODE_VERSION environment variable in the Netlify dashboard. This seems to have successfully set the version number to 12.18.0 (according to our build logs), but I’m still getting the same issue unfortunately. Could there be something else perhaps?

With regards to the second issue, happy to provide any verification you need from us. Would we potentially be able to provide the verification to have the site transferred over to our Netlify account from Michael’s instead (to save having to debug this further)? No worries if that’s not a possibility.


Hi, @ChorusAgency. I noticed the two sites are using different version of our build image (one is using xenial and the other focal). You might try changing those to match as well.

You might also just try making a new site with the repo on your existing team to see if you can reproduce the error that way. That way you will have a working and non-working version on the same team without needing to transfer.

I say this because the node dependencies install tools (both npm and yarn) are famously non-deterministic in their behavior. Just because two developers are using the same package.json file in no way means both developers’ dependencies are perfectly matched. In other words, simply creating a new site linked to the repo may help you to reproduce the error as it may only show up with a fresh npm install. (The repo is private, though, so this is just a guess.)

If you do decide to move the two sites to the same team to troubleshoot, please ask the owner of the team where the site to be moved is currently to request the transfer with our support team. To do so, please have them email from their team owner email address (as found at and let us know the following:

  • the site subdomain (or site API ID) for any sites to be transfer (like
  • if there are DNS zones attached, tell us if we should transfer those as well or not
  • the owner email address for the team where the sites should be transferred to

For example, I might write in from and say this:

Hello Netlify Support Team,

Would you transfer my site to the team owned by you@chorusagency.tld (or whatever your email address is)?

We will reply back to ask for confirmation and if they confirm we’ll transfer the site or sites.

Hi Luke

Thanks for getting back to me about this.

I tried updating the build image to xenial and rebuilt the site but that has not worked either.

Just to clarify, our existing (working) website is

The reason we have set up a new Netlify account and build the website on a new domain name ( is because the old website is under our previous freelance developer’s (Michael’s) Netlify account.

Michael has not worked for us for a while now, we’ve tried to contact him many times over the past few weeks to ask him to give us access to the Netlify control panel or transfer ownership over to us but we are not getting a response from him.

Given that we don’t have access to the first website, I think much of the info in the second half of your response is not applicable.

We’d be very happy to have that repo transferred over from Michael’s account, to our own new account. If that was possible, it would negate the need to keep new site and debug this issue we’re having with the project page. But from what I understand you’ll need Michael to contact you to arrange that. I’m afraid we cannot get in touch with Michael to ask him to do that given the circumstances.

Is there any other way around this? We’re happy to provide any proof that would help establish that we are the rightful owners of the site.


Hi @luke just wondering if there’s any update on this? Thanks

Hi, @ChorusAgency. We can transfer sites between team but we usually recommend unlinking the repo from the site before transferring to the current site. We then ask the new site owner to link a repo they do control to the site.

In other words, the repo isn’t controlled by Netlify. We can transfer the site to your control but not the repo as we have no way to do this.

As far as proving you own the site, at Netlify that is done by having the email address and password required to login. If you don’t have that you don’t own the site.

If someone has uploaded copyrighted content that you own you can make a DMCA takedown report and we can suspend the site but we don’t transfer it to your control. We can only do transfer with an email from the current site owner.

I’m showing the two sites are now linked to two different repos now and it appears your site is building successfully. Do you still want us to email the current site owner and ask them for permission to transfer the site?

I also see there is a custom domain assigned to this site. We can remove the custom domain from the existing site if a verification DNS record is created:

​Please let us know if you would prefer to do a DNS verification or if we should email the site owner. If there are further questions about this, please let us know.

Hi @luke

I explained in a previous post when discussing this issue with Perry that we own the repo and that the two repos for the two different Netlify sites are the same repo - please see this post for more info which includes a video showing that redirects to
One codebase, two different deployment results? - #7 by ChorusAgency

With that being the case, is it required to unlink the repo before transferring it or can we try transferring while the repo is still linked? I’m cautious of doing anything that may disrupt the working site.

It would be great if you could email the current site owner on our behalf. As I mentioned, we’ve not been able to get in contact with him ourselves on multiple occasions.

If we can’t get in touch with him, we’re going to have to dig deeper into the issue and try and figure out what’s going on, but I must say I’m not an expert with npm. I still can’t understand how two Netlify builds from the exact same GitHub repo can have different results, especially when they’ve both had rebuilds triggered recently so we know they’re both up to date. Any idea where I should even begin to look with this?

Morning @luke, is there any further update on this please?


Hi @ChorusAgency :wave:

Thanks for your patience here. I want to assure you we have not forgotten about your case here! A member of the support team will follow up shortly.

Hiya @ChorusAgency and sorry to hear this trouble persists!

What we usually say to folks in your situation is that “you’ve built something differently; you should debug how what you’ve built now is different than what you build before.” I understand that without access to the old site, this will be hard for you, but it’s still our guidance - we can’t really help you debug problems with your source code (we don’t know it well enough to know what could be different). I know that this manifests as “it works differently on Netlify than this other site that should be identical” and indeed, I can see very deployments at the old and new site - for instance, there is a different number of files generated in each deploy (99 vs 98), which generally indicates that something more substantial than a change in your site settings or a change in “how we are serving the site”.

Since we can’t transfer the old site to you, I wonder how we can help you do this. I suppose that the old site is public, so I could export a copy of it for you, and then you could compare with a copy you’ve built, and debug from there, so that’s what I’ll propose for now. If that appeals, let me know and we’ll get you a copy shortly! If not, I don’t really have any more suggestions as to what could be happening.