How to create a new testnet from scratch

Hi, I the found instructions to launch a node, ( but how can I launch more than one and create a new testnet?


Hi @jrosich! If you want just to run cluster locally you can specify -n option. For example, cargo run -p libra_swarm -- -s -n 4, will do config management for you and will spawn network of 4 validators locally


Hi, what I want to do is run a testnet with my friends around the world. Can we do that?

1 Like

How to run a real node so I can participate with my peers directly?

Sure, it’s possible. Unfortunately we don’t have nice tutorial for that yet.
But basically you’ll need to replicate what libra_swarm does for you behind the scenes.
It includes:

  • generate keypair for genesis account: `cargo run --bin generate_keypair – -o <path_to_output_file>
  • generate configs for nodes for your future network. You can do it via cargo run --bin libra-config. Here you’ll need to specify number of nodes in cluster, path to genesis account, base template(example of such is available in config/data/configs/node.config.toml)
  • distribute configs for each node to your friends
  • finally run separate node locally via `cargo run --bin libra_node – -f <path_to_config> -p <peer_id>

Hopefully, we will have it documented better soon


Having this process well-documented would be greatly appreciated!

What is the peer_id in the last step?

@trusty @jrosich

Sorry for the self-promotion, but I have this process (mostly) well-documented here:

This shows you how to setup the local testnet, share the config files and setup basic security & networking architecture to connect remote clients into it

1 Like

Hi @jonrau1. I actually saw your repo. Great writeup. However, I’m mostly interested in setting up a cluster of validator nodes, e.g. multiple EC2 instances.

meaning we can set up this node and let other connect to it (explorers) and let 3rd parties create custom modules/smartcontracts in it ?


You can specify multiple validators on your testnet with the -n flag, I haven’t put mine through the wringer as hard as I would like but you should not run into a lot of latency, especially with the (kind of) SBFT consensus mechanism under the covers of LibraBFT versus POW/POS/POA.

I am working on a new change right now to put multiple nodes behind an ALB, not sure how well it would work given every time you run swarm the Admission Control Service Port changes – @phoenix can we override that value in the *.config.node.toml file?

I at least want to make sure I can come into it from behind an ALB


My distro is dealing with RFC1918 address spaces, but I am experimenting with connecting to the Public IP, but theoretically yes, you could put an explorer on top of it – I am not sure how to execute a Move module / SC yet, but I imagine that would be possible to in it

1 Like

AFAIK the -n flag only spins up multiple nodes on the same host. I’m trying to do the same thing as you. Something like multiple hosts behind an ALB.

Working it right now – having issues connecting to my public IPV4 address but can do private no problem at all, I have Allow All Traffic between both SGs as well, super weird

Testing out resolving with a NLB right now – since it’s all TCP anyway

(though you can resolve an Internal ALB by IP from the external NLB and go from target groups in there)

EDIT – I guess in the same subnet/VPC it won’t let you egress the VPC and return to it, but from another VPC I could resolve the Public IP address

Working through getting a health check override on the targets so I can resolve via NLB, 443 & the service port are both draining my targets, researching how to overcome this


So I found that in the same VPC, I could not resolve the Public IP address, but was able to from another VPC as well as “on-prem” (my laptop) – so that was pretty easy. Though, when I quit and reconnect, it forgets my old wallet, which doesnt happen with the RFC1918 host target.

Regarding Load Balancing - I first tried an IP-target NLB with the RFC1918 space of the local blockchain network node, that would not resolve no matter what. To get the target to register, I had to create an Override Health Check on Port 80 and throw NGINX on the instance, but made the SG rule only allow HTTP traffic from my VPC /16

I swapped to an Instance target with the Listener – that was able to work, but, everytime I back quit the client and reconnect to the NLB DNS A Record, it creates a new wallet for me.

Will be experimenting with the ALB instead, definitely need some session stickiness of some sort

(or to remember to load mnemonics)

just fyi. Count me in if anyone want one more validator node joining in. So far there is still issues to complete all transactions from clients to validator node. Working on it.