# Several IPFS nodes with the same keys? **URL:** \ **Category:** Help\ **Created:** [February 15, 2022, 5:08pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485 "2022-02-15T17:08:08Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![PDVJAM](https://avatars.discourse-cdn.com/v4/letter/p/47e85d/32.png) [@PDVJAM](https://discuss.ipfs.tech/u/PDVJAM)\ **Post date:** [February 15, 2022, 5:08pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/1 "2022-02-15T17:08:08Z")
Is this possible to have several IPFS nodes with the same keys across them? What we want is to store our files on several nodes, but we would like to access them via IPNS names, and as I understand we need the same key on all nodes to have the same IPNS name on them. Is this possible at all? ---
**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\ **Post date:** [February 15, 2022, 5:17pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/2 "2022-02-15T17:17:13Z")
Multiple nodes with the same peer ID is a big no no and doesn’t work. However you can have alternative keys to use for IPNS (see `ipfs key --help`), if you have duplicates of that, it does likely not much. One of the peer counter will be higher than the other and only that peer publishes will go through. (that a guess, I havn’t actually tested maybe I’m wrong). However, you don’t need to have IPNS running on all nodes for them to share the files. You can have a single node publishing IPNS and other ones just storing the same CIDs behind the IPNS record. (there is still a single point of failure for the IPNS publishing but all nodes will serve the files). ---
**Author:** ![PDVJAM](https://avatars.discourse-cdn.com/v4/letter/p/47e85d/32.png) [@PDVJAM](https://discuss.ipfs.tech/u/PDVJAM)\ **Post date:** [February 15, 2022, 5:19pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/3 "2022-02-15T17:19:49Z")
How can I copy files already uploaded from the first node to other nodes? Is there some kind of sync or something like that? ---
**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\ **Post date:** [February 15, 2022, 5:23pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/4 "2022-02-15T17:23:27Z")
Run this on the other nodes: ```auto ipfs pin add Qmfoo ``` Replace `Qmfoo` with your CID. That kinda of a pain because you need to do that on all nodes, personally for that I use: [cluster.ipfs.io](http://cluster.ipfs.io) you add or pin the file once, and it get broadcasted to all the nodes. ---
**Author:** ![LeDechaine](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ledechaine/32/8841_2.png) [@LeDechaine](https://discuss.ipfs.tech/u/LeDechaine)\ **Post date:** [September 10, 2024, 7:32pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/5 "2024-09-10T19:32:13Z")
I was searching for that and, you can link IPNS **names** to IPFS content. Redirecting a .crypto / .wallet (from Unstoppable Domains) address to an IPFS link, or a “.eth” (Ethereum domain) to an IPFS link (or even, as shown below, a simple [DNSLink](https://dnslink.dev/) to your “web 2.0” domain via DNS). Then your domain.crypto or domain.eth (or [domain.com](http://domain.com)) will link to **all** nodes. i.e., what I was looking for, and what you are looking for if you arrived here (hi!) could also be [this](https://github.com/ipfs/kubo/blob/master/docs/config.md#gateway-recipes), or something similar. ```auto Hardened, site-specific DNSLink gateway. Disable fetching of remote data (NoFetch: true) and resolving DNSLink at unknown hostnames (NoDNSLink: true). Then, enable DNSLink gateway only for the specific hostname (for which data is already present on the node), without exposing any content-addressing Paths: $ ipfs config --json Gateway.NoFetch true $ ipfs config --json Gateway.NoDNSLink true $ ipfs config --json Gateway.PublicGateways '{ "en.wikipedia-on-ipfs.org": { "NoDNSLink": false, "Paths": [] } }' ``` **Gateway.NoDNSLink** is set to false by default, which means Kudo will resolve “TXT” DNSLinks in name servers, by default. Does it also resolve .eth/.crypto domain names (etc.) by default too, now? Looks like it does. Neat stuff! 👍 (Edit: Otherwise, [this](https://github.com/ipfs/kubo/blob/master/docs/config.md#dnsresolvers) fixes it.) ---
**Author:** ![LeDechaine](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ledechaine/32/8841_2.png) [@LeDechaine](https://discuss.ipfs.tech/u/LeDechaine)\ **Post date:** [July 10, 2025, 6:32am UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/6 "2025-07-10T06:32:12Z")
EDIT: _Well, I should have first mentioned my website is only .html files and images. So:_ _ **Warning: This ONLY works for a static website, which you update all the ipfs instances at the same time. On anything non-static, as explained below by @ylempereur, these instructions will just… create a real mess** (i.e.: a random number of people will be accessing a random snapshot of your website done a random point in recent time – **always** )._ * * * Guess what. One year later and I finally was able to try everything properly and I can now tell you, _ **YES, it’s possible to have the same exact, immutable, IPNS key for multiple servers, and it works.** _ The standard kubo instance only has (auto-generated) “self” keys, but you can create other keys: > ipfs key gen super > ipfs key export super (The key will then be saved as _super.key_ in the current folder.) Then, you take this _super.key_ file, and put it in the other server(s), possibly somewhere in the .ipfs folder to avoid weird “permission denied” errors. And on all these other server(s) you do: > ipfs key import super super.key > ipfs key list -l **ipfs key list -l** will give you the long CID of the “super” key. Then, on **all** your servers, you will be able to: > ipfs name publish --key=(_long-superkey-IPNS-CID_) (_your-latest-files-IPFS-cid_) Your IPFS CIDs can change as much as they want, they will now always be linked by an **immutable** IPNS CID – just like a domain name. _Yes. The same IPNS address. Forever. Associated to **multiple** servers._ No need to install an IPFS Cluster. No need to buy a _.eth_ or any other domain. Otherwise, no need to update your DNSLinks anymore, because it will always be the same IPNS address! I find it so odd that there’s basically **no info AT ALL** on this when the **main** thing about IPFS is redundancy, i.e. the ability to host things on multiple servers. **I spent two years thinking an IPNS key had to mean “one IP address of one machine”, therefore you had to get a domain name and update IPFS links all the time… _until I found this message from 2017._** > [@IPNS publishing after generating a key](https://discuss.ipfs.tech/t/ipns-publishing-after-generating-a-key/90/4): > > Wow, I tested it via HTTP APIs you linked and it seems to… work just fine. rocket Not sure why you had different IPNS hash, but I got the feeling you were regenerating key instead of generating it only once and copying it to all nodes that should be able to publish with it. I wrote a short instruction, check if you were following the same steps: Publishing with the same key from two different nodes I generated a new key under alias “test”: nodeA $ curl 'http://localhost:5001/api/v0/key/ge… **This really needs to be added everywhere in the help files and how-to’s.** Otherwise it seems like it’s impossible to even _host a simple, static website on multiple servers linked to one immutable address_ unless you spend a lot of time and money with IPFS Clusters and IPLD (?) and whatever else… But this might be just how the “big data guys” working with IPFS for a living do it too? _I just did not **knew** it!_ _P.S.:_ Some guy at IPFS sure likes to have fun. Searching for base32/base36 encodings and which ones work and don’t, and at the end of the list was… base256emoji. > [https://ipfs.io/ipfs/🚀🪐⭐💻😅😍🌼✌👌😉👋💔🤘🤐✈✊💿👈💣👎😕🤬😰😱😆😎🖤😶🙊🐶💎😒💜😴💕😀🦋](https://ipfs.io/ipfs/%F0%9F%9A%80%F0%9F%AA%90%E2%AD%90%F0%9F%92%BB%F0%9F%98%85%F0%9F%98%8D%F0%9F%8C%BC%E2%9C%8C%F0%9F%91%8C%F0%9F%98%89%F0%9F%91%8B%F0%9F%92%94%F0%9F%A4%98%F0%9F%A4%90%E2%9C%88%E2%9C%8A%F0%9F%92%BF%F0%9F%91%88%F0%9F%92%A3%F0%9F%91%8E%F0%9F%98%95%F0%9F%A4%AC%F0%9F%98%B0%F0%9F%98%B1%F0%9F%98%86%F0%9F%98%8E%F0%9F%96%A4%F0%9F%98%B6%F0%9F%99%8A%F0%9F%90%B6%F0%9F%92%8E%F0%9F%98%92%F0%9F%92%9C%F0%9F%98%B4%F0%9F%92%95%F0%9F%98%80%F0%9F%A6%8B) > This is an actual website. This is [https://en.wikipedia-on-ipfs.org/](https://en.wikipedia-on-ipfs.org/) … _encoded in “base256emoji”_. _P.S. 2: Parenthesis: Unstoppable domains._ I don’t know if “.eth” domains work, but Unstoppable Domains will not allow you to put something starting with “k51…” (any IPNS key) in the “IPFS” infos. You can: > ipfs cid format -v 1 -b base32 (k51…) Which will change your key to base32 (starting with “bafzaa…”). The website will accept it… then mess everything up. Because it will redirect to ipfs .io/ **ipfs** /bafzaa…(etc). : and give an _Internal server error_, because it’s supposed to be ipfs .io/ **ipns** /bafzaa…(etc). So, add that to the [list of things Unstoppable Domains screwed up](https://github.com/ipfs/boxo/issues/772), I guess. _ **Anyway… enjoy!** _ ---
**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\ **Post date:** [July 10, 2025, 3:15pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/7 "2025-07-10T15:15:18Z")
Eek, don’t do that, it’s a **really** bad idea and it will not work properly. @Jorropo tried to explain why in his first post to this thread, but I guess you either missed it or didn’t understand it. I’ll try and clarify the two reasons why this won’t work: Each node keeps a counter along with each ipns key that it uses to number each ipns record when you publish. The latest record it **itself** published is then reprovided every four hours. Here is what that looks like: Let’s say you only have one node and you publish a new CID on a new key. Let’s call the new CID A. The record will be published with a count of 1. Let’s call this record 1A. From that point on, the node will reprovide record 1A every 4 hours. Let’s say you then publish a newer CID, B. this will create ipns record 2B, which will then be reprovided every 4 hours. If you again publish an even newer CID, C, the newest record 3C will now be reprovided every 4 hours. Let’s say you did this fairly quickly, all three records still exist in the DHT. If a client looks up your key, **all three** records will be returned! The client will choose the one with the highest counter, 3C, and use that. If you duplicate the key to another node and publish a newer CID, D, it will create record 1D and start reproviding it every four hours. From this point on, the first node is reproviding 3C and the second node is reproviding 1D. If a client looks up your key, both records will be returned, and it will choose 3C as the latest (highest count). If you publish a new CID to the second node, you end up with 2E, and a client still chooses 3C. Publish again, and you have 3F. Now, a client will choose randomly between 3C and 3F, for each lookup. Add a third node, and now you have a real mess. The point is, you still only have one node reproviding your latest record, and clients may choose a different record coming from another node just because it has a higher count. In short, it won’t do what you want. What you are looking for is ipns record re-pinning, which is a fairly recent thing that some providers have started to support. You still only have one node that publishes new records, with only one counter, but you have other nodes picking up that latest record when it appears, and re-pinning it and helping reprovide it from that point on. So, now, you have multiple nodes providing that latest record, making it more available. ---
**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\ **Post date:** [July 10, 2025, 3:42pm UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/8 "2025-07-10T15:42:13Z")
See [feat(ipns): Add a parameter in name.publish to change the sequence number. by gsergey418 · Pull Request #10851 · ipfs/kubo · GitHub](https://github.com/ipfs/kubo/pull/10851) which is related and should in theory allow re-publishing safely from different places, assuming those places coordinate on the sequence number. ---
**Author:** ![LeDechaine](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ledechaine/32/8841_2.png) [@LeDechaine](https://discuss.ipfs.tech/u/LeDechaine)\ **Post date:** [July 11, 2025, 6:51am UTC](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485/9 "2025-07-11T06:51:18Z")
> [@ylempereur](#): > > In short, it won’t do what you want. I should have pointed out that my website is a **static** website _(and above all, I will add a note at the start of my last message… **do not** do that when your website is not just simple .html files etc, for obvious reasons)_. I fully understand that on **anything** non-static, my way of doing it will be a real mess. Now… for my **static** website? That’s exactly what I want. I want my website to always be available, even if one of the multiple IPFS instances crash (and that is all). I obviously update my IPNS “super.key” on all the IPFS instances at the same time. > If you publish a new CID to the second node, you end up with 2E, and a client still chooses 3C. Publish again, and you have 3F. Now, a client will choose randomly between 3C and 3F, for each lookup. Oh well, as a bonus, it also acts as a load balancer. _Neat!_ _Edit: Yeah I also had messed up and said my website was non-static somewhere in my last message I’m sorry. 😬_