diff --git a/docs/community/contribute/overview.md b/docs/community/contribute/overview.md
index 8eeaa33cfff..0bdc5f2a9a6 100644
--- a/docs/community/contribute/overview.md
+++ b/docs/community/contribute/overview.md
@@ -28,7 +28,7 @@ As part of the NEAR contributor program
 If you are interested in testing our documentation, guides and developer tools, head over to the following pages. We would love to jump on a call and get to know your insights, or you can submit directly issues in the respective repositories on GitHub. For more information on where and how to file issues, please head over to our [developer contribution section.](/docs/community/contribute/how-to-contribute)
 
 - [Developer tools](/docs/develop/basics/create-account)
-- [Local development](/docs/develop/node/running-a-node)
+- [Local development](/docs/develop/node/validator/running-a-node)
 - [Introduction to near-api-js](/docs/develop/front-end/introduction)
 
 #### Development
diff --git a/docs/concepts/networks.md b/docs/concepts/networks.md
index 3ad159e8d48..25642a0e0d2 100644
--- a/docs/concepts/networks.md
+++ b/docs/concepts/networks.md
@@ -10,7 +10,7 @@ NEAR Protocol operates on several networks each operating with their own indepen
 * [`testnet`](/docs/concepts/networks#testnet)
 * [`betanet`](/docs/concepts/networks#betanet)
 * [`localnet`](/docs/concepts/networks#localnet)
-  
+
 ---
 
 ## `mainnet`
@@ -53,7 +53,7 @@ NEAR Protocol operates on several networks each operating with their own indepen
 
 > LocalNet is intended for developers who want to work with the NEAR platform independent of the public blockchain. You will need to generate nodes yourself.
 
-More on local development [here](/docs/develop/node/running-a-node)
+More on local development [here](/docs/develop/node/validator/running-a-node)
 
 `near-cli` [network selection](/docs/tools/near-cli#network-selection) variable is `local`
 
diff --git a/docs/develop/front-end/introduction.md b/docs/develop/front-end/introduction.md
index 36e74a6823b..a2a03165add 100644
--- a/docs/develop/front-end/introduction.md
+++ b/docs/develop/front-end/introduction.md
@@ -77,7 +77,7 @@ If you prefer a more experimental and rapid approach, try the following:
 
 1. Explore [NEAR Examples](http://near.dev/) to deploy one of several sample applications in minutes. You will be able to deploy them using Gitpod's web-hosted environment, modify the code, play with them in the browser there and view transactions on the blockchain via an explorer or wallet. You can modify this code into your own apps.
 2. Use your own development environment to create dApps
-   1. Beginner level setup (recommended): [TestNet](/docs/develop/node/running-a-node)
+   1. Beginner level setup (recommended): [TestNet](/docs/develop/node/validator/running-a-node)
 3. Follow our introductory [JavaScript library Guides](/docs/tutorials/front-end/naj-examples) to
    1. Create an account
    2. Authenticate with NEAR CLI
diff --git a/docs/develop/node/archival/hardware-archival.md b/docs/develop/node/archival/hardware-archival.md
new file mode 100644
index 00000000000..811e9503db5
--- /dev/null
+++ b/docs/develop/node/archival/hardware-archival.md
@@ -0,0 +1,55 @@
+---
+id: hardware-archival
+title: Hardware Requirements for Archival Node
+sidebar_label: Hardware Requirements
+description: NEAR Archival Node Hardware Requirements
+---
+
+This page covers the minimum and recommended hardware requirements for engaging with the NEAR platform as an Archival node.
+
+
+## Recommended Hardware Specifications
+
+| Hardware       |  Recommended Specifications                                               |
+| -------------- | -----------------------------------------------------------------------   |
+| CPU            | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support            |
+| RAM            | 16GB DDR4                                                                 |
+| Storage        | 2 Terabyte SSD                                                            |
+
+_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
+
+
+## Minimal Hardware Specifications
+
+| Hardware       |  Minimal Specifications                                                    |
+| -------------- | -------------------------------------------------------------------------- |
+| CPU            | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support             |
+| RAM            | 8GB DDR4                                                                   |
+| Storage        | 1.5 Terabyte SSD                                                           |
+
+_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
+
+## Cost Estimation
+
+Estimated monthly costs depending on operating system:
+
+| Cloud Provider | Machine Size    | Linux                  |
+| -------------- | --------------- | ---------------------- |
+| AWS            | c5.2xlarge      | $150 CPU + $20 storage |
+| GCP            | c2-standard-8   | $250 CPU + $20 storage |
+| Azure          | Standard_F8s_v2 | $180 CPU + $10 storage |
+
+<blockquote class="info">
+<strong>Resources for Cost Estimation</strong><br><br>
+
+All prices reflect *reserved instances* which offer deep discounts on all platforms with a 1 year commitment
+
+- AWS
+  - cpu: https://aws.amazon.com/ec2/pricing/reserved-instances/pricing
+  - storage: https://aws.amazon.com/ebs/pricing
+- GCP
+  - cpu: https://cloud.google.com/compute/vm-instance-pricing
+  - storage: https://cloud.google.com/compute/disks-image-pricing
+- Azure — https://azure.microsoft.com/en-us/pricing/calculator
+
+</blockquote>
diff --git a/docs/develop/node/community/node-community-updates.md b/docs/develop/node/community/node-community-updates.md
new file mode 100644
index 00000000000..58f714af961
--- /dev/null
+++ b/docs/develop/node/community/node-community-updates.md
@@ -0,0 +1,51 @@
+---
+id: node-community-updates
+title: Node Community Updates
+sidebar_label: Node Community Updates
+description: NEAR Node and Validator Community Updates
+---
+
+## NEAR Validator Community Channels
+
+NEAR Protocol will communicate with validators using these channels:
+
+1. Releases of `nearcore` are on Github repository of [`nearcore`](https://github.com/near/nearcore/issues).
+
+2. Bugs and feature enhancements are tracked in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18). Node operators are welcome to create new issues for features and bugs, and to add these issues into the [Github project tracker](https://github.com/orgs/near/projects/18).
+    - **New feature / Enhancement requests:**  
+        - Please create a [`Github issue`](https://github.com/near/nearcore/issues)
+        - Tag `nodeX`
+        - Filter them through `Incoming Requests` column in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18), where they will be groomed and moved into `Backlog` based on priority
+    - **Bug reports:**
+        - Please create a [`Github issue`](https://github.com/near/nearcore/issues)
+        - Tag `nodeX` and `Bug`
+        - Put it at the top of the `Incoming Requests` column for more immediate attention in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18)
+
+3. Technical support and troubleshooting by the NEAR team are available in the Validator Channels on [Discord](https://discord.gg/ZMPr3VB) and on [Telegram](https://t.me/near_validators).
+
+4. Discussions on upcoming changes and early ideation are on [gov.near.org](https://gov.near.org/c/staking-delegation/5).
+
+
+<blockquote class="info">
+<strong>Heads up</strong><br><br>
+
+As a node operator, you are welcome to create bugs and feature requests on Github to improve the experience of running a node. Head to [`nearcore`](https://github.com/near/nearcore/issues) repository on Github to open an issue, and don't forget to tag the issue with the `nodeX` tag.
+
+</blockquote>
+
+
+
+**Runtime Alerts:**
+
+To keep our network healthy and minimize the damage of potential incidents, the NEAR team would like to establish a process with which we communicate updates and emergency situations with validators so that they can respond promptly to properly sustain the operations of the network. To this end, we propose that we use different tags in important messages to validators so that they can be easily picked up by automated systems on validators’ end.
+
+The tags we propose are as follows:
+
+`[CODE_RED_<network_id>]` where `<network_id>` is either `MAINNET` or `TESTNET`. This represents the most dire and urgent situation. Usually it means that the network has stalled or crashed and we need validators to take **immediate** actions to bring the network up. Alternatively it could mean that we discovered some highly critical security vulnerabilities and a patch is needed as soon as possible. If it is about mainnet, we expect that validators will react immediately to such alerts, ideally within 30 minutes.
+
+`[CODE_YELLOW_<network_id>]` where `<network_id>` is either `MAINNET` or `TESTNET`. This represents a less urgent announcement. Usually it means the release of a protocol change or a fix of a moderate security issue. In such cases, validators are not expected to take immediate actions but are still expected to react within days.
+
+`[CODE_GREEN_<network_id>]` where `<network_id>` is either `MAINNET` or `TESTNET`. This usually means some general announcement that is more informational or doesn’t require actions within a short period of time. It could be an announcement of a release that improves performance or a fix some minor issues.
+
+
+Call-to-actions for technical teams if the network is stalling and there's the need to coordinate a manual node restart. Such messages begin with `[CODE_RED_BETANET]` or `[CODE_RED_TESTNET]`, and will be posted in the read-only Validator Announcement channel on [Discord](https://discord.gg/xsrHaCb). The same message may be repeated in other channels, to have higher outreach.
diff --git a/docs/validator/keys.md b/docs/develop/node/intro/keys.md
similarity index 85%
rename from docs/validator/keys.md
rename to docs/develop/node/intro/keys.md
index b2e87689577..936fd20e29b 100644
--- a/docs/validator/keys.md
+++ b/docs/develop/node/intro/keys.md
@@ -1,30 +1,31 @@
 ---
 id: keys
-title: Keys on the NEAR Platform
-sidebar_label: Understanding Keys
+title: Key Management
+sidebar_label: Key Management
+description: NEAR Node Key Management
 ---
 
-## what are keys?
+## What are Keys?
 
-In public key cryptography we need a key pair, one public and one private, to sign and send verifiable transactions across the network. NEAR takes the common approach of using public keys for identity and private keys for signatures. Internally the NEAR platform uses ed25519, one of several "elliptic curves" that produce secure cryptographic results quicky. Specifically, we use `tweetnacl` in JavaScript and `libsodium` in Rust.
+In public key cryptography, there is a key pair, one public and one private, to sign and send verifiable transactions across the network. NEAR takes the common approach of using public keys for identity and private keys for signatures. Internally the NEAR platform uses ed25519, one of several "elliptic curves" that produce secure cryptographic results quicky. Specifically, we use `tweetnacl` in JavaScript and `libsodium` in Rust.
 
-## are there different kinds of keys?
+## Are there Different Types of Keys?
 
 There are 3 types of key pairs on the NEAR platform
 
-- signer keys (aka. account keys, access keys, etc)
-- validator keys
-- node keys
+- Signer Keys (aka. account keys, access keys, etc)
+- Validator Keys
+- Node Keys
 
-**Signer keys** are the ones we all know and love. They're used by all accounts on the network to sign transactions like `sendMoney` and `stake` before sending them to the network. Signer keys are not related to running a node in any way. End users who sign up through the [NEAR Wallet](https://wallet.betanet.near.org/) get their own signer keys, for example. These are the keys that humans think about and keep safe.
+**Signer Keys** are the ones we all know and love. They're used by all accounts on the network to sign transactions like `sendMoney` and `stake` before sending them to the network. Signer keys are not related to running a node in any way. End users who sign up through the [NEAR Wallet](https://wallet.betanet.near.org/) get their own signer keys, for example. These are the keys that humans think about and keep safe.
 
 There are two flavors of signer keys currently available, `FullAccess` keys and `FunctionCall` keys. The first has unrestricted control to "act on behalf of an account" (as used by NEAR CLI and NEAR Wallet to get things done for you). The second is limited to contract storage and compute. Both flavors of keys can be revoked by the account holder. There is no limit to the flavors of keys that the NEAR platform can handle so we can easily imagine keys for voting, shopping, conducting official business, etc. each with their own access controls on our data, programmable time limits, etc. But keep in mind that you do have to pay rent on keys issued to your account.
 
-**Validator keys** are used by validators (people and companies who are committed to maintaining the integrity of the system) to support their work of validating blocks and chunks on the network, nothing more. The human validators don't think about these keys beyond creating them and resetting them. Once added to a validator's node, validator keys are used by the node to do their thing of validating blocks and chunks. As a convenience to validators, validator keys are currently produced by a script at node startup if they don't already exist (in the case of NEAR Stake Wars, the `start_stakewars.py` script) but this may change.
+**Validator Keys** are used by validators (people and companies who are committed to maintaining the integrity of the system) to support their work of validating blocks and chunks on the network, nothing more. The human validators don't think about these keys beyond creating them and resetting them. Once added to a validator's node, validator keys are used by the node to do their thing of validating blocks and chunks. As a convenience to validators, validator keys are currently produced by a script at node startup if they don't already exist (in the case of NEAR Stake Wars, the `start_stakewars.py` script) but this may change.
 
-**Node keys** are something no humans on the network think about except core contributors to the platform. These keys are used internally by a node to sign low-level communications with other nodes in the network like sending block headers or making other verifiable requests. Node keys are currently provided to a node at startup by a script. In the case of NEAR Stake Wars it's the `start_stakewars.py` script that produces these keys for now, but this may change.
+**Node Keys** are something no humans on the network think about except core contributors to the platform. These keys are used internally by a node to sign low-level communications with other nodes in the network like sending block headers or making other verifiable requests. Node keys are currently provided to a node at startup by a script. In the case of NEAR Stake Wars it's the `start_stakewars.py` script that produces these keys for now, but this may change.
 
-## can keys be changed?
+## Can Keys be Changed?
 
 Yes, but only in that keys can be _reset_ (ie. regenerated as a new key pair). If a private key is lost or compromised somehow then a new key pair must be generated. This is just the nature of secure keys.
 
@@ -35,7 +36,7 @@ Yes, but only in that keys can be _reset_ (ie. regenerated as a new key pair). I
 **Nodes** should not need to reset their node keys.
 
 <blockquote class="info">
-<strong>did you know?</strong><br><br>
+<strong>Did you know?</strong><br><br>
 
 As a brief word on the NEAR runtime, the subsystem that manages state transitions on the blockchain (ie. keeping things moving from one block to the next), it's worth understanding that the movement of the system happens in stages, called epochs, during which the group of validators does not change. The [Nightshade whitepaper](https://near.org/downloads/Nightshade.pdf) introduces epochs this way: "the maintenance of the network is done in epochs, where an epoch is a period of time on the order of days." and there's much more detail in the paper.
 
@@ -55,7 +56,6 @@ If validator keys are changed _during an epoch in which the validator is staking
 For concrete examples of keys being used as identifiers, you can see a list of validators and active nodes on various NEAR networks here:
 
 - NEAR TestNet (staking currently disabled)
-
   - https://rpc.testnet.near.org/status
   - https://rpc.testnet.near.org/network_info
 
diff --git a/docs/develop/node/intro/types-of-node.md b/docs/develop/node/intro/types-of-node.md
new file mode 100644
index 00000000000..34d62210d20
--- /dev/null
+++ b/docs/develop/node/intro/types-of-node.md
@@ -0,0 +1,17 @@
+---
+id: types-of-node
+title: Types of Node
+sidebar_label: Types of Node
+description: Types of NEAR Node
+---
+
+You can run three different types of node - Validator Node, RPC Node, and Archival Node.
+
+## Validator Node
+Validator Nodes are the operators of the NEAR blockchain and are essential to the health of the network. Validator nodes participate in the consensus and produce blocks and/or chunks"
+
+## RPC Node
+RPC Nodes are RPC service providers for that provide public RPC endpoints for developers to use. The NEAR Foundation currently maintains a public RPC endpoint `http://rpc.mainnet.near.org/` that is free for everyone to use. However, any participants are encouraged to run their own RPC node and offer RPC services through a grant from the NEAR Foundation. For more information, please reach out in Validator channels on Telegram or Discord.
+
+## Archival Node
+Archival Nodes store full blockchain data, and build an archive of historical states. These nodes are useful for block explorers, chain analytics, and infrastructure providers.
diff --git a/docs/develop/node/intro/what-is-a-node.md b/docs/develop/node/intro/what-is-a-node.md
new file mode 100644
index 00000000000..71caff3337a
--- /dev/null
+++ b/docs/develop/node/intro/what-is-a-node.md
@@ -0,0 +1,23 @@
+---
+id: what-is-a-node
+title: What is a Node
+sidebar_label: What is a Node
+description: What is a NEAR Node and Why Run a Node
+---
+
+NEAR Protocol runs on a collection of publicly maintained computers (or "nodes"). All nodes are running the same `nearcore` codebase with the latest releases available on [Github](https://github.com/near/nearcore/releases/). In the following section, we will introduce three types of nodes.
+
+It is important to keep in mind all nodes runs the same codebase, but with different configurations. As such we have split up the instructions for running different nodes into different sections.
+
+## Why run a Node?
+
+You may decide to run a node of your own for a few reasons:
+
+- To join a network as a validator running a "validator node". Running a validator node is a public good and you are effectively securing the NEAR network and earning rewards.
+- To develop and deploy contracts on a node connected to `MainNet`, `TestNet` or `BetaNet` (†)
+- To develop and deploy contracts on a local (independent and isolated) node (sometimes called "LocalNet"). (††)
+- To quickly extract blockchain data that can be used for chain analytics
+
+_( † ) `TestNet` is intended to operate as similarly to `MainNet`  as possible with only stable releases while `BetaNet` follows a weekly release cycle._
+
+_( †† ) `LocalNet` would be the right choice if you prefer to avoid leaking information about your work during the development process since `TestNet` and `BetaNet` are *public* networks. `LocalNet` also gives you total control over accounts, economics and other factors for more advanced use cases (ie. making changes to `nearcore`)._
diff --git a/docs/develop/node/maintenance/maintenance.md b/docs/develop/node/maintenance/maintenance.md
new file mode 100644
index 00000000000..1d5ae0385bf
--- /dev/null
+++ b/docs/develop/node/maintenance/maintenance.md
@@ -0,0 +1,37 @@
+---
+id: maintenance
+title: Node Maintenance
+sidebar_label: Node Maintenance
+description: NEAR Node Maintenance and Network Updates
+---
+
+## Updating a Node
+
+As a decentralized network, every update to NEAR Protocol needs some coordination between end users, platforms, developers, and validators. [`nearup`](https://github.com/near/nearup) provides scripts to launch NEAR Protocol `TestNet` and `BetaNet` nodes. Unless it is executed with the switch `--binary-path`, `nearup` will automatically update the local binaries if NEAR's boot nodes fork the network and change the genesis checksum.
+
+For security-critical applications and for validators, `nearup` can run a locally compiled binary of [`nearcore`](https://github.com/near/nearcore), but such updates have to be done manually. Since validators are responsible for creating new blocks, coordination in this process is necessary to avoid any network stall.
+
+
+## Planned Updates
+
+NEAR merges node updates from [nearcore releases](https://github.com/near/nearcore/releases) as follows:
+- `BetaNet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-beta`
+- `TestNet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-rc`
+- `MainNet` is not yet subject to planned releases
+
+Once `MainNet: Restricted` is live, planned updates to `TestNet` and `MainNet` will come via coordination with validators.
+
+<blockquote class="warning">
+<strong>Heads up</strong><br><br>
+
+`BetaNet` provides cutting-edge testing grounds for validators, with weekly updates and frequent hard-forks. `BetaNet` is using the `beta` branch of `nearcore`, which is merged every Wednesday at 00:00 UTC and deployed on NEAR boot nodes shortly after.
+</blockquote>
+
+
+## Emergency Updates
+
+We may issue a `[CODE_YELLOW_TESTNET]` or `[CODE_YELLOW_MAINNET]` if the network is suffering minor issues, or a new software release introduces incompatibilities and requires additional testing.
+
+NEAR Protocol team will use the tag `[CODE_RED_TESTNET]` or `[CODE_RED_MAINNET]` in the Validator Announcement channel on [Discord](https://discord.gg/xsrHaCb), followed by email instructions for coordination. Some updates may follow a confidential process, as explained on [nearcore/SECURITY.md](https://github.com/near/nearcore/blob/master/SECURITY.md) docs.
+
+NEAR's team will be mostly active on [Github](https://github.com/near/nearcore), and with limited participation on Discord and Telegram.
diff --git a/docs/develop/node/rpc/hardware-rpc.md b/docs/develop/node/rpc/hardware-rpc.md
new file mode 100644
index 00000000000..f32527bccd3
--- /dev/null
+++ b/docs/develop/node/rpc/hardware-rpc.md
@@ -0,0 +1,54 @@
+---
+id: hardware-rpc
+title: Hardware Requirements for RPC Node
+sidebar_label: Hardware Requirements
+description: NEAR RPC Node Hardware Requirements
+---
+
+This page covers the minimum and recommended hardware requirements for engaging with the NEAR platform as a RPC node.
+
+## Recommended Hardware Specifications
+
+| Hardware       |  Recommended Specifications                                               |
+| -------------- | -----------------------------------------------------------------------   |
+| CPU            | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support            |
+| RAM            | 16GB DDR4                                                                 |
+| Storage        | 200GB SSD (NVMe SSD is recommended. HDD will be enough for localnet only )|
+
+_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
+
+
+## Minimal Hardware Specifications
+
+| Hardware       |  Minimal Specifications                                                    |
+| -------------- | -------------------------------------------------------------------------- |
+| CPU            | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support             |
+| RAM            | 8GB DDR4                                                                   |
+| Storage        | 150GB SSD (NVMe SSD is recommended. HDD will be enough for localnet only)  |
+
+_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
+
+## Cost Estimation
+
+Estimated monthly costs depending on operating system:
+
+| Cloud Provider | Machine Size    | Linux                  |
+| -------------- | --------------- | ---------------------- |
+| AWS            | c5.2xlarge      | $150 CPU + $20 storage |
+| GCP            | c2-standard-8   | $250 CPU + $20 storage |
+| Azure          | Standard_F8s_v2 | $180 CPU + $10 storage |
+
+<blockquote class="info">
+<strong>Resources for Cost Estimation</strong><br><br>
+
+All prices reflect *reserved instances* which offer deep discounts on all platforms with a 1 year commitment
+
+- AWS
+  - cpu: https://aws.amazon.com/ec2/pricing/reserved-instances/pricing
+  - storage: https://aws.amazon.com/ebs/pricing
+- GCP
+  - cpu: https://cloud.google.com/compute/vm-instance-pricing
+  - storage: https://cloud.google.com/compute/disks-image-pricing
+- Azure — https://azure.microsoft.com/en-us/pricing/calculator
+
+</blockquote>
diff --git a/docs/develop/node/compile-and-run-a-node.md b/docs/develop/node/validator/compile-and-run-a-node.md
similarity index 93%
rename from docs/develop/node/compile-and-run-a-node.md
rename to docs/develop/node/validator/compile-and-run-a-node.md
index 0282efa91ee..530eee0f82e 100644
--- a/docs/develop/node/compile-and-run-a-node.md
+++ b/docs/develop/node/validator/compile-and-run-a-node.md
@@ -1,15 +1,15 @@
 ---
 id: compile-and-run-a-node
-title: Compile and run a node
-sidebar_label: Compile and run a node
+title: Compile and Run without Container
+sidebar_label: Compile and Run without Container
+description: Compile and Run a NEAR Node without Container in localnet, testnet, and mainnet
 ---
 
-# How to compile and run nearcore
-
 This doc is written for developers, sysadmins, DevOps, or curious people who want to know how to compile and run a regular NEAR node natively (without containerization) for one of the following networks:
-- [`mainnet`](/docs/develop/node/compile-and-run-a-node#mainnet)
-- [`testnet`](/docs/develop/node/compile-and-run-a-node#testnet)
-- [`localnet`](/docs/develop/node/compile-and-run-a-node#localnet)
+
+- [`localnet`](/docs/develop/node/validator/compile-and-run-a-node#localnet)
+- [`testnet`](/docs/develop/node/validator/compile-and-run-a-node#testnet)
+- [`mainnet`](/docs/develop/node/validator/compile-and-run-a-node#mainnet)
 
 ## Prerequisites
 
@@ -26,12 +26,6 @@ This doc is written for developers, sysadmins, DevOps, or curious people who wan
     $ apt install -y git binutils-dev libcurl4-openssl-dev zlib1g-dev libdw-dev libiberty-dev cmake gcc g++ python docker.io protobuf-compiler libssl-dev pkg-config clang llvm
     ```
 
-### Recommended hardware:
-- 4 CPU cores
-- 16GB RAM
-- 100GB SSD (HDD will be enough for localet only)
-
-
 ## How to use this document
 
 This document is separated into sections by network ID. Although all of the sections have almost the exact same steps/text, we found it more helpful to create individual sections so you can easily copy-paste commands to quickly get your node running.
@@ -40,9 +34,9 @@ This document is separated into sections by network ID. Although all of the sect
 
 When building your NEAR node you will have two branch options to choose from depending on your desired use:
 
-- `master` : _(**Experimental**)_ 
+- `master` : _(**Experimental**)_
   - Use this if you want to play around with the latest code and experiment. This branch is not guaranteed to be in a fully working state and there is absolutely no guarantee it will be compatible with the current state of *mainnet* or *testnet*.
-- [`Latest release branch`](https://github.com/near/nearcore/releases) : _(**Stable**)_ 
+- [`Latest release branch`](https://github.com/near/nearcore/releases) : _(**Stable**)_
   - Use this if you want to run a NEAR node for *mainnet* or *tesnet*. This version is used by validators and other nodes and is fully compatible with the current state of *mainnet* or *testnet*.
 
 ## `localnet`
@@ -56,7 +50,7 @@ $ git clone https://github.com/near/nearcore
 $ cd nearcore
 ```
 
-Next, checkout the release branch you need if you will not be using the default `master` branch. [ [More info](/docs/develop/node/compile-and-run-a-node#choosing-your-nearcore-version) ]
+Next, checkout the release branch you need if you will not be using the default `master` branch. [ [More info](/docs/develop/node/validator/compile-and-run-a-node#choosing-your-nearcore-version) ]
 
 ```bash
 $ git checkout master
@@ -81,7 +75,7 @@ In order to work properly, the NEAR node requires a working directory and a coup
 - `config.json` - Configuration parameters which are responsive for how the node will work.
 - `genesis.json` - A file with all the data the network started with at genesis. This contains initial accounts, contracts, access keys, and other records which represents the initial state of the blockchain.
 - `node_key.json` -  A file which contains a public and private key for the node. Also includes an optional `account_id` parameter which is required to run a validator node (not covered in this doc).
-- `data/` -  A folder in which a NEAR node will write it's state.
+- `data/` -  A folder in which a NEAR node will write its state.
 - `validator_key.json` - A file which contains a public and private key for local `test.near` account which belongs to the only local network validator.
 
 Generate the initial required working directory by running:
@@ -176,7 +170,7 @@ $ wget ~/.near/config.json https://s3-us-west-1.amazonaws.com/build.nearprotocol
 
 The node is ready to be started however you must first sync up with the network. This means your node needs to download all the headers and blocks that other nodes in the network already have. You can speed up this process by downloading backups in one of two ways:
 
-1. Download and unpack the [tar file](https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/testnet/rpc/data.tar) to `~/.near`. 
+1. Download and unpack the [tar file](https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/testnet/rpc/data.tar) to `~/.near`.
 
 or
 
@@ -212,7 +206,7 @@ $ cd nearcore
 
 Next, checkout the release branch you need (recommended) if you will not be using the default `master` branch. Please check the [releases page on GitHub](https://github.com/near/nearcore/releases) for the latest release. Currently `1.19.0` as of 5/25/21.
 
-For more information on choosing between `master` and latest release branch [ [click here](/docs/develop/node/compile-and-run-a-node#choosing-your-nearcore-version) ].
+For more information on choosing between `master` and latest release branch [ [click here](/docs/develop/node/validator/compile-and-run-a-node#choosing-your-nearcore-version) ].
 
 ```bash
 $ git checkout tags/1.19.0 -b mynode
diff --git a/docs/validator/mainnet-phase-one.md b/docs/develop/node/validator/deploy-on-mainnet.md
similarity index 85%
rename from docs/validator/mainnet-phase-one.md
rename to docs/develop/node/validator/deploy-on-mainnet.md
index 7c47bbaf37a..7262171ec7c 100644
--- a/docs/validator/mainnet-phase-one.md
+++ b/docs/develop/node/validator/deploy-on-mainnet.md
@@ -1,12 +1,11 @@
 ---
 id: deploy-on-mainnet
-title: Deploy a Validator Node on MainNet
-sidebar_label: Deploy on MainNet
+title: Deploy Node on MainNet
+sidebar_label: Deploy Node on MainNet
 ---
 
-## Step-by-Step guide
 
-Overall, the process is similar to TestNet and BetaNet:
+Deploying a node on MainNet is similar to deploying on TestNet and BetaNet:
 1. Create your MainNet wallet
 2. Deploy your MainNet staking pool
 3. Build and run your MainNet validator node
@@ -14,7 +13,7 @@ Overall, the process is similar to TestNet and BetaNet:
 ### 1. Create your MainNet Wallet
 - Go to [wallet.near.org](https://wallet.near.org/) and create an account.
 
-### 2. Deploy your MainNet staking pool
+### 2. Deploy your MainNet Staking Pool
 You can instantly deploy the staking pool with [near-cli](https://github.com/near/near-cli), using the command `near call`:
 
 ```
@@ -27,7 +26,7 @@ The command will invoke the `staking-pool-factory` from [NEAR Core Contracts](ht
 - `POOL_ID` is the name of your validator (and the staking pool associated with it)
 - `OWNER_ID` is the wallet that controls the pool, see the [owner-only methods](https://github.com/near/core-contracts/tree/master/staking-pool#owner-only-methods) for more information
 - `VALIDATOR_KEY` is the validator node public key, from the file `~/.near/validator_key.json`
-- `{"numerator": <X>, "denominator": <Y>}` set the validator fees. `x=10` and `y=100` equals to 10% 
+- `{"numerator": <X>, "denominator": <Y>}` set the validator fees. `x=10` and `y=100` equals to 10%
 - `--amount 30` attaches 30 $NEAR to the transaction to pay the contract storage
 - `--gas 300000000000000` specifies the amount of gas for the transaction (optional)
 
@@ -64,17 +63,13 @@ cargo build -p neard --release
 ```
 
 - configure the `chain-id` and `account-id`:
-  
+
 ```bash
 target/release/neard init --chain-id="mainnet" --account-id=<YOUR_STAKING_POOL_ID>
 ```
-  - After the build process is done, check that the configuration file located at `/HOME_DIR/.near/config.json` is the same as [this one](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json).
- 
+  - After the build process is done, check that the configuration file located at `/HOME_DIR/.near/config.json` is the same as [this mainnet config.json](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json).
+
   - Now, start your node with the following command:
 ```
 target/release/neard run
 ```
-
->Got a question?
-<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
-  <h8>Ask it on StackOverflow!</h8></a>
diff --git a/docs/develop/node/validator/hardware.md b/docs/develop/node/validator/hardware.md
new file mode 100644
index 00000000000..a22f49b9722
--- /dev/null
+++ b/docs/develop/node/validator/hardware.md
@@ -0,0 +1,54 @@
+---
+id: hardware
+title: Hardware Requirements for Validator Node
+sidebar_label: Hardware Requirements
+description: NEAR Validator Node Hardware Requirements
+---
+
+This page covers the minimum and recommended hardware requirements for engaging with the NEAR platform as a validator node.
+
+## Recommended Hardware Specifications
+
+| Hardware       |  Recommended Specifications                                     |
+| -------------- | --------------------------------------------------------------- |
+| CPU            | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support  |
+| RAM            | 16GB DDR4                                                       |
+| Storage        | 200GB SSD (HDD will be enough for localnet only)                |
+
+_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
+
+
+## Minimal Hardware Specifications
+
+| Hardware       |  Minimal Specifications                                         |
+| -------------- | --------------------------------------------------------------- |
+| CPU            | 2-Core (4-Thread) Intel i7/Xeon or equivalent with AVX support  |
+| RAM            | 8GB DDR4                                                        |
+| Storage        | 150GB SSD (HDD will be enough for localnet only)                |
+
+_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
+
+## Cost Estimation
+
+Estimated monthly costs depending on operating system:
+
+| Cloud Provider | Machine Size    | Linux                  |
+| -------------- | --------------- | ---------------------- |
+| AWS            | c5.2xlarge      | $150 CPU + $20 storage |
+| GCP            | c2-standard-8   | $250 CPU + $20 storage |
+| Azure          | Standard_F8s_v2 | $180 CPU + $10 storage |
+
+<blockquote class="info">
+<strong>Resources for Cost Estimation</strong><br><br>
+
+All prices reflect *reserved instances* which offer deep discounts on all platforms with a 1 year commitment
+
+- AWS
+  - cpu: https://aws.amazon.com/ec2/pricing/reserved-instances/pricing
+  - storage: https://aws.amazon.com/ebs/pricing
+- GCP
+  - cpu: https://cloud.google.com/compute/vm-instance-pricing
+  - storage: https://cloud.google.com/compute/disks-image-pricing
+- Azure — https://azure.microsoft.com/en-us/pricing/calculator
+
+</blockquote>
diff --git a/docs/develop/node/running-a-node.md b/docs/develop/node/validator/running-a-node-macos-linux.md
similarity index 75%
rename from docs/develop/node/running-a-node.md
rename to docs/develop/node/validator/running-a-node-macos-linux.md
index 451e06aec54..a3ae67e4303 100644
--- a/docs/develop/node/running-a-node.md
+++ b/docs/develop/node/validator/running-a-node-macos-linux.md
@@ -1,40 +1,27 @@
 ---
 id: running-a-node
-title: Running a node
-sidebar_label: Running a node
+title: Run a Node on Linux and MacOS
+sidebar_label: Run a Node (Linux and MacOS)
+Description: How to run a NEAR node using nearup on Linux and MacOS, with or without using Docker.
 ---
 
-## Why?
+This doc is written for developers, sysadmins, DevOps, or curious people who want to know how to run a NEAR node using `nearup` on Linux and MacOS, with or without using Docker.
 
-NEAR Protocol runs on a collection of publicly maintained computers (or "nodes").
-
-You may decide to run a node of your own for a few reasons:
-
-- To develop and deploy contracts on a node connected to `MainNet`, `TestNet` or `BetaNet` (†)
-- To develop and deploy contracts on a local (independent and isolated) node (sometimes called "LocalNet"). (††)
-- To join a network as a validator running a "validator node" (see [staking](/docs/validator/staking))
-
-_( † ) `TestNet` is intended to operate as closely (similarly) to `MainNet`  as possible with only stable releases while `BetaNet` follows a weekly release cycle._
-
-_( †† ) `LocalNet` would be the right choice if you prefer to avoid leaking information about your work during the development process since `TestNet` and `BetaNet` are *public* networks. `LocalNet` also gives you total control over accounts, economics and other factors for more advanced use cases (ie. making changes to `nearcore`)._
 
 ## `nearup` Installation
-
 You can install `nearup` by following the instructions at https://github.com/near/nearup.
 
 <blockquote class="info">
-<strong>heads up</strong><br><br>
-
-The README for `nearup` (linked above) may be **all you need to get a node running**.
+<strong>Heads up</strong><br><br>
 
-This page is made available to clarify a few points of confusion along the way for those who need it.
+The README for `nearup` (linked above) may be **all you need to get a node up and running** in `betanet` and `testnet`. `nearup` is exclusively used to launch NEAR `betanet` and `testnet` nodes. `nearup` is not used to launch `mainnet` nodes.
 
 </blockquote>
 
 The steps in the rest of this document will require `nearup`
 
 
-## Running an Official Node using Docker
+## Running a Node using Docker
 
 ### Install Docker
 
@@ -45,7 +32,7 @@ Follow these instructions to install Docker on your machine:
 * [MacOS](https://docs.docker.com/docker-for-mac/install/)
 * [Ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)
 
-NOTE: You can run a node without Docker by adding the `--nodocker` flag to the `nearup` command and specifying the compiled binary path. See how to do this in the next section: [Compiling and Running an Official Node without Docker](/docs/develop/node/running-a-node#compiling-and-running-official-node-testnetbetanet-without-docker).
+NOTE: You can run a node without Docker by adding the `--nodocker` flag to the `nearup` command and specifying the compiled binary path. See how to do this in the next section: [Compiling and Running an Official Node without Docker](/docs/develop/node/validator/running-a-node#compiling-and-running-official-node-testnetbetanet-without-docker).
 
 ### Running `nearup`
 
@@ -80,7 +67,7 @@ To check the logs inside Docker, run `docker logs --follow nearcore`.
 
 
 
-## Compiling and Running Official Node without Docker
+## Compiling and Running a Node without Docker
 
 Alternatively, you can build and run a node without Docker by compiling `nearcore` locally and pointing `nearup` to the compiled binaries. Steps in this section provide details of how to do this.
 
@@ -142,7 +129,7 @@ You will then be prompted for an Account ID. You can leave this empty if you wou
 Enter your account ID (leave empty if not going to be a validator):
 ```
 
-## Running Official Node on GCP
+## Running a Node on GCP
 
 Create new instance, with at least:
 
@@ -170,7 +157,7 @@ Once you have followed the steps for running a node with Docker or of Compiling
 Using local binary at path/to/nearcore/target/release
 Our genesis version is up to date
 Starting NEAR client...
-Node is running! 
+Node is running!
 To check logs call: `nearup logs` or `nearup logs --follow`
 ```
 
@@ -181,10 +168,6 @@ Using local binary at path/to/nearcore/target/release
 Our genesis version is up to date
 Stake for user 'stakingpool.youraccount.betanet' with 'ed25519:6ftve9gm5dKL7xnFNbKDNxZXkiYL2cheTQtcEmmLLaW'
 Starting NEAR client...
-Node is running! 
+Node is running!
 To check logs call: `nearup logs` or `nearup logs --follow`
 ```
-
->Got a question?
-<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
-  <h8>Ask it on StackOverflow!</h8></a>
diff --git a/docs/develop/node/running-a-node-windows.md b/docs/develop/node/validator/running-a-node-windows.md
similarity index 78%
rename from docs/develop/node/running-a-node-windows.md
rename to docs/develop/node/validator/running-a-node-windows.md
index edb9e50cbe4..65296bf1a74 100644
--- a/docs/develop/node/running-a-node-windows.md
+++ b/docs/develop/node/validator/running-a-node-windows.md
@@ -1,9 +1,30 @@
 ---
 id: running-a-node-windows
-title: Running a Node on Windows
-sidebar_label: Running a node (Windows)
+title: Run a Node on Windows
+sidebar_label: Run a Node (Windows)
+description: How to run a NEAR node using `nearup` on Windows
 ---
 
+This doc is written for developers, sysadmins, DevOps, or curious people who want to know how to run a NEAR node using `nearup` on Windows.
+
+
+<blockquote class="warning">
+<strong>Heads up</strong><br><br>
+This documentation may require additional edits. Please keep this in mind while running the following commands.
+</blockquote>
+
+
+## `nearup` Installation
+You can install `nearup` by following the instructions at https://github.com/near/nearup.
+
+<blockquote class="info">
+<strong>Heads up</strong><br><br>
+
+The README for `nearup` (linked above) may be **all you need to get a node up and running** in `betanet` and `testnet`. `nearup` is exclusively used to launch NEAR `betanet` and `testnet` nodes. `nearup` is not used to launch `mainnet` nodes.
+
+</blockquote>
+
+
 1.  If Windows Subsystem for Linux is not enabled, open PowerShell as administrator and run:
     ```sh
     Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
@@ -60,7 +81,7 @@ sidebar_label: Running a node (Windows)
     ```
     Great! All set to get the node up and running!
 11. Clone the github nearcore
-    
+
     First we need to check a version which is currently working in testnet:
     ```sh
     curl -s https://rpc.testnet.near.org/status | jq .version
@@ -84,13 +105,9 @@ sidebar_label: Running a node (Windows)
     ```sh
     nearup run testnet --binary-path ~/nearcore/target/release/
     ```
-    To be sure node is ruuning you can check logs 
+    To be sure node is ruuning you can check logs
     ```sh
     nearup logs --follow
     ```
 
 You might be asked for a validator ID; if you do not want to validate, simply press enter. For validation, please refer to the [validation section](validator/staking.md).
-
->Got a question?
-<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
-  <h8>Ask it on StackOverflow!</h8></a>
diff --git a/docs/roles/integrator/exchange-integration.md b/docs/roles/integrator/exchange-integration.md
index 3f1bd79c534..e84f0021076 100644
--- a/docs/roles/integrator/exchange-integration.md
+++ b/docs/roles/integrator/exchange-integration.md
@@ -795,7 +795,7 @@ http post https://rpc.mainnet.near.org method=block params:='{"finality":"final"
 
 ## Running an Archival Node
 
-- Setting up an archival node is the same as a [regular node](/docs/develop/node/running-a-node), but modifying your `config.json` by changing `archive` to `true` and specifying `tracked_shards`. Please make sure that the node is stopped while changing the config.
+- Setting up an archival node is the same as a [regular node](/docs/develop/node/validator/running-a-node), but modifying your `config.json` by changing `archive` to `true` and specifying `tracked_shards`. Please make sure that the node is stopped while changing the config.
 
 The config should contain the following fields, currently NEAR testnet and mainnet have only 1 (zero indexed) shard and that shard is tracked.
 
diff --git a/docs/roles/validator/hardware.md b/docs/roles/validator/hardware.md
deleted file mode 100644
index 94374feaebd..00000000000
--- a/docs/roles/validator/hardware.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-id: hardware
-title: Hardware Requirements
-sidebar_label: Choosing Hardware
----
-
-This page covers the minimum and recommended hardware requirements for engaging with the NEAR platform as an application developer, validator, integrator or core contributor.
-
-## Machine Specifications
-
-- **CPU:** 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support
-- **RAM:** 16GB DDR4
-- **Storage:** 100GB SSD
-
-_Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx```. If the output is empty, your CPU is not supported._
-
-Estimated monthly costs depending on operating system:
-
-| Cloud Provider | Machine Size    | Linux                  |
-| -------------- | --------------- | ---------------------- |
-| AWS            | c5.2xlarge      | $150 CPU + $20 storage |
-| GCP            | c2-standard-8   | $250 CPU + $20 storage |
-| Azure          | Standard_F8s_v2 | $180 CPU + $10 storage |
-
-<blockquote class="info">
-<strong>Resources for Cost Estimation</strong><br><br>
-
-All prices reflect *reserved instances* which offer deep discounts on all platforms with a 1 year commitment
-
-- AWS
-  - cpu: https://aws.amazon.com/ec2/pricing/reserved-instances/pricing
-  - storage: https://aws.amazon.com/ebs/pricing
-- GCP
-  - cpu: https://cloud.google.com/compute/vm-instance-pricing
-  - storage: https://cloud.google.com/compute/disks-image-pricing
-- Azure — https://azure.microsoft.com/en-us/pricing/calculator
-
-</blockquote>
-
->Got a question?
-<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
-  <h8>Ask it on StackOverflow!</h8></a>
diff --git a/docs/validator/maintenance.md b/docs/validator/maintenance.md
deleted file mode 100644
index 23634c05d8c..00000000000
--- a/docs/validator/maintenance.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: maintenance
-title: Validator Node Maintenance
-sidebar_label: Node Maintenance
----
-
-## Updating a Validator Node
-
-As a decentralized network, every update to NEAR Protocol needs some coordination between end users, platforms, developers and validators. [`nearup`](https://github.com/near/nearup) provides scripts to launch NEAR Protocol `TestNet` and `BetaNet` nodes. Unless it is executed with the switch `--binary-path`, `nearup` will automatically update the local binaries if NEAR's boot nodes fork the network and change the genesis checksum.
-
-For security-critical applications and for validators, `nearup` can run a locally compiled binary of [`nearcore`](https://github.com/near/nearcore), but such updates have to be done manually. Since validators are responsible for creating new blocks, coordination in this process is necessary to avoid any network stall.
-
-## NEAR Validator Channels
-
-NEAR Protocol will communicate with validators using these channels:
-
-1. **Runtime Alerts:** call-to-actions for technical teams if the network is stalling and there's the need to coordinate a manual node restart. Such messages begin with `[CODE_RED_BETANET]` or `[CODE_RED_TESTNET]`, and will be posted in the read-only Validator Announcement channel on [Discord](https://discord.gg/xsrHaCb). The same message may be repeated in other channels, to have higher outreach.
-2. Technical troubleshooting in the Validator Channel on [Discord](https://discord.gg/ZMPr3VB).
-3. New releases, technical support and bug tracking in the Github repos of [Stake Wars](https://github.com/nearprotocol/stakewars/issues) and [`nearcore`](https://github.com/near/nearcore/issues).
-
-We may issue a `[CODE_YELLOW_BETANET]` or `[CODE_YELLOW_TESTNET]` if the network is suffering minor issues, or a new software release introduces incompatibilities and requires additional testing.
-
-NEAR's team will be mostly active on Github, and with limited participation on Discord and Telegram.
-
-
-## Planned Updates
-
-NEAR merges node updates from [nearcore releases](https://github.com/near/nearcore/releases) as follows:
-- `BetaNet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-beta`
-- `TestNet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-rc`
-- `MainNet` is not yet subject to planned releases
-
-Once `MainNet: Restricted` is live, planned updates to `TestNet` and `MainNet` will come via coordination with validators.
-
-<blockquote class="warning">
-<strong>heads up</strong><br><br>
-
-`BetaNet` provides cutting-edge testing grounds for validators, with weekly updates and frequent hard-forks. `BetaNet` is using the `beta` branch of `nearcore`, which is merged every Wednesday at 00:00 UTC and deployed on NEAR boot nodes shortly after. `BetaNet` is also the network used for Stake Wars.
-
-</blockquote>
-
-
-## Emergency Updates
-
-NEAR Protocol team will use the tag `[CODE_RED_BETANET]` or `[CODE_RED_TESTNET]` in the Validator Announcement channel on [Discord](https://discord.gg/xsrHaCb), followed by email instructions for coordination. Some updates may follow a confidential process, as explained on [nearcore/SECURITY.md](https://github.com/near/nearcore/blob/master/SECURITY.md) docs.
-Follow the [Stake Wars](https://near.org/stakewars) if you want to participate in fire-drills and test your playbook for emergency updates.
-
->Got a question?
-<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
-  <h8>Ask it on StackOverflow!</h8></a>
diff --git a/docs/validator/staking-faq.md b/docs/validator/staking-faq.md
index 4db76b04e04..b6af811dd85 100644
--- a/docs/validator/staking-faq.md
+++ b/docs/validator/staking-faq.md
@@ -19,7 +19,7 @@ The collection of transactions for the shard is called a chunk. Once a chunk and
 ### How do I become a validator?
 
 You need an account with sufficient amount of funds.
-Follow the docs [here](/docs/validator/staking) to understand how to become a validator, and [here](/docs/develop/node/running-a-node) to run a node.
+Follow the docs [here](/docs/validator/staking) to understand how to become a validator, and [here](/docs/develop/node/validator/running-a-node) to run a node.
 
 More specific steps:
 1. Create a new key pair that will be used for staking for given account, and load it with the funds you want to put at stake
@@ -72,7 +72,7 @@ Large validators will have to generate blocks signing across multiple shards, th
 
 ### How do I run a node?
 
-Follow [this tutorial.](/docs/develop/node/running-a-node)
+Follow [this tutorial.](/docs/develop/node/validator/running-a-node)
 
 ### Do validators receive incentives for testing the protocol?
 
diff --git a/docs/validator/staking.md b/docs/validator/staking.md
index d1b55f5566d..82580bbd3de 100644
--- a/docs/validator/staking.md
+++ b/docs/validator/staking.md
@@ -30,13 +30,13 @@ TestNet is running on separate URLs for the explorer, the wallet and the Json RP
 
 Every new TestNet account receives automatically a few hundred tokens to deploy smart contracts and test your APIs.
 
-You can use [nearup](https://github.com/near/nearup) to easily deploy your TestNet node on a VPS. If you plan to deploy on MainNet, **you can't use nearup**, and we suggest to follow the guidelines [here](deploy-on-mainnet).
+You can use [nearup](https://github.com/near/nearup) to easily deploy your TestNet node on a VPS. If you plan to deploy on MainNet, **you can't use nearup**, and we suggest to follow the guidelines [here](/docs/develop/node/validator/deploy-on-mainnet).
 Join NEAR validator channels [on Discord](https://near.chat) to receive technical support by NEAR team and the rest of the community.
 
 NEAR Validators should:
 
 - Know how to compile, deploy and configure NEAR Validator nodes
-- Understand the difference between `account_key`, `node_key`and `validator_key` (see the [keys on NEAR Platform](keys) doc)
+- Understand the difference between `account_key`, `node_key`and `validator_key` (see the [keys on NEAR Platform](/docs/develop/node/intro/keys) doc)
 - Understand how to deploy a NEAR contract, and the difference betweek `view` and `call` methods. Know how to leverage them via `near-cli` and `near RPC`
 - Have a monitoring platform in place, to measure the generated and missed blocks, peers and connectivity, current node version, along with the typical cpu, memory, storage and networking performance
 - Understand the state of a validator: `proposals`, `next` and `current`
@@ -53,7 +53,7 @@ At least 16GB RAM
 At least 100GB SSD (Note: HDD will not work)
 ```
 
-More information is on the [Hardware Requirements](../roles/validator/hardware) docs.
+More information is on the [Hardware Requirements](/docs/develop/node/validator/hardware) docs.
 
 ## Setting up your environment
 
@@ -77,7 +77,7 @@ Once Near CLI is installed, go ahead and run your node.
 
 ## Run the Node
 
-Please follow [Nearup documentation](https://github.com/near/nearup) to start your TestNet node. Remeber that `nearup` doesn't support MainNet, so you will have to build your startup scripts and follow the [mainnet deployment guide](deploy-on-mainnet).
+Please follow [Nearup documentation](https://github.com/near/nearup) to start your TestNet node. Remeber that `nearup` doesn't support MainNet, so you will have to build your startup scripts and follow the [mainnet deployment guide](/docs/develop/node/validator/deploy-on-mainnet).
 
 At the first start, nearup will ask your validator account ID. Put a placeholder, like `coming_soon`, to let the node sync with the network while you deploy the staking pool:
 
@@ -250,7 +250,7 @@ You can use `near-cli` to review the validator set in the next three epochs:
 
 <blockquote class="warning">
     <strong>Heads Up!</strong><br><br>
-    You have to wait at least 2 epochs (43,200 blocks each) before your 
+    You have to wait at least 2 epochs (43,200 blocks each) before your
 </blockquote>
 
 **Note:** The default network for `near-cli` is `testnet`. If you would like to change this to `mainnet` or `betanet`, please see [`near-cli` network selection](/docs/tools/near-cli#network-selection) for instructions.
@@ -264,7 +264,7 @@ NEAR Protocol automatically re-stake all inflationary rewards, unless you decide
 - [Lockup contracts explained](../tokens/lockup)
 - [NEAR Core Contracts on Github](https://github.com/near/core-contracts)
 - [NEAR Stake Wars](https://github.com/nearprotocol/stakewars)
-  
+
 >Got a question?
 <a href="https://stackoverflow.com/questions/tagged/nearprotocol">
   <h8>Ask it on StackOverflow!</h8></a>
diff --git a/website/sidebars.json b/website/sidebars.json
index f036ac4822d..c57139ec23e 100644
--- a/website/sidebars.json
+++ b/website/sidebars.json
@@ -60,15 +60,60 @@
         ]
       }
     ],
-    "Running A Node": [
-      "develop/node/running-a-node",
-      "develop/node/running-a-node-windows",
-      "develop/node/compile-and-run-a-node"
+    "Run A Node": [
+      {
+        "type": "subcategory",
+        "label": "Introduction",
+        "ids": [
+          "develop/node/intro/what-is-a-node",
+          "develop/node/intro/types-of-node",
+          "develop/node/intro/keys"
+        ]
+      },
+      {
+        "type": "subcategory",
+        "label": "Run a Validator Node",
+        "ids": [
+          "develop/node/validator/hardware",
+          "develop/node/validator/compile-and-run-a-node",
+          "develop/node/validator/running-a-node",
+          "develop/node/validator/running-a-node-windows",
+          "develop/node/validator/deploy-on-mainnet"
+        ]
+      },
+      {
+        "type": "subcategory",
+        "label": "Run a RPC Node",
+        "ids": [
+          "develop/node/rpc/hardware-rpc"
+        ]
+      },
+      {
+        "type": "subcategory",
+        "label": "Run a Archival Node",
+        "ids": [
+          "develop/node/archival/hardware-archival"
+        ]
+      },
+      {
+        "type": "subcategory",
+        "label": "Maintenance",
+        "ids": [
+          "develop/node/maintenance/maintenance"
+        ]
+      },
+      {
+        "type": "subcategory",
+        "label": "Community",
+        "ids": [
+          "develop/node/community/node-community-updates"
+        ]
+      }
     ],
-    "NEAR <> ETH": [  
+    "NEAR <> ETH": [
           "develop/eth/evm",
           "develop/eth/rainbow-bridge"
-        ]
+    ]
   },
   "tutorials": {
     "General": [
@@ -81,7 +126,7 @@
       "tutorials/front-end/naj-workshop"
     ],
     "Smart Contracts": [
-      
+
       {
         "type": "subcategory",
         "label": "AssemblyScript",
@@ -102,7 +147,7 @@
     "Rainbow Bridge": [
       "tutorials/rainbow-bridge-frontend-mainnet",
       "tutorials/rainbow-bridge-frontend-testnet"
-      
+
     ],
     "Videos": [
       "videos/accounts-keys",
@@ -149,12 +194,8 @@
       "validator/delegation"
     ],
     "Validator": [
-      "roles/validator/hardware",
       "validator/staking",
-      "validator/keys",
-      "validator/maintenance",
-      "validator/economics",
-      "validator/deploy-on-mainnet"
+      "validator/economics"
     ],
     "FAQ": [
       "validator/staking-faq"