# 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:** 1\ **Showing post:** 6
**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!** _ --- _[View the full topic](https://discuss.ipfs.tech/t/several-ipfs-nodes-with-the-same-keys/13485)._