The HaystackRootServer is instantiated in one of two modes, root, and non-root. A user is always assumed to be running one HaystackRootServer running in root mode. The server running in root mode causes a number of event driven services and the HDM objects to be loaded automatically into the VM's memory space. HDM objects are currently loaded only into a root HaystackRootServer as Haystack does not currently support a concurrency model robust enough to allow for manipulation of HDM structures outside of the main HaystackRootServer's scope. There are various pre-existing solutions that describe the implementation of distributed object management that may be suitable for intergration into Haystack in the future.
A non-root HaystackRootServer is used for the purposes of loading services that need to run outside the root-VM. For example, if a user has mutiple computers and wishes to archive the files on both into one Haystack, they can run a non-root HaystackRootServer with an archiver service on one machine and a HaystackRootServer in root mode on the other. All data then gets aggregated from the non-root to the root HaystackRootServer and the data from both machines is indexed together. For services that need to decide if they are running under a root or non-root context, HaystackRootServer provides a static method, amIRoot() to answer that question.
To successfully create a HaystackRootServer, a user must both instantiate and initialize the HaystackRootServer object. Instantiation is done through the standard new operator, and initialization through the init() procedure of the HaystackRootServer. It is important to note that the HaystackRootServer utilizes a variant of the singleton pattern[18] to insure that only one copy of the server is running in a given VM. The init() method takes a configuration file, and an optional port as arguments. The port is used for binding the Middleman service, and the configuration file is routed to the HsConfigService for further processing. Furthermore, the HaystackRootServer will invoke the init() procedure on the HsNameService as well as the HsConfigService (these are the two essential services we need to bootstrap). Additionally, we can terminate the HaystackRootServer by calling the close() method which will close the HsNameService.
The only other vital function of the HaystackRootServer is
the ability to statically call for a number of the bootstrap services.
Table 
shows the static data member in the
HaystackRootServer and its corresponding value.
| Static variable | Points at |
| myNameService | The HsNameService running under this HaystackRootServer. This allows us to lookup a pointer to any service. |
| myConfigService | The HsConfigService, holds global settings |
| myDebugger | HsDebug, a tool for debugging Haystack |
| myErrLogger | HsError, a tool to deal gracefully with errors |
| myPersistentStore | The HsPersistentObjectService |
| myObjCreator | The HsObjectCreatorService |
| myMsgLogger | HsMessage, for non-error messages |
| myDispatcher | The HsDispatcher, so that new services can register their interest in HDM subgraphs. |
| myCounter | The HsCounter service generates unique IDs |
| mySendable | The appropriate Middleman object for this root server. |