Spawngrid: on-demand Plan 9 environments

2 December 2018

The spawning grid is a worldwide network of Plan 9 servers which provide on-demand cpu environments from a library of stored filesystem snapshots. Users can spawn and cpu in to container-like independent namespaces with a private root filesystem. Multiple environments can be spawned on the same or different grid servers. New fs snapshots can be created at any time, and also shared with other users on the grid.

The spawning grid is currently invite-only to existing Plan 9 community members - if you use Plan 9 and participate in the 9gridchan public grid, or Plan 9 related freenode irc channels, mailing lists, discord, whatever - you are invited to email mycroftiv at with a username and password request. Doing so indicates that you understand these free services are for legal, non-commercial personal use and you won't use them for anything uncool. No guarantees are made about availability or data retention and service may be terminated at will, but I'm hoping that this service and all data created will be available for many years.

Using the spawngrid

After an account has been created, add the spawngrid server information to your /lib/ndb/local. It can be found at, or after the end of the text of this page. Then download the gridorc script from or copy it from the bottom of this page. Run gridorc as follows:

gridorc -u gridusername -h gridstorageserver

To choose a value for 'gridstorageserver' check the grid ndb info. There are servers in Frankfort (Germany) Paris (France) New Jersey (USA) Chicago (USA) and San Francisco (USA). The storage servers all begin with a location identifier followed by 'spasto' - so if you want the servers in Paris, the -h parameter for gridorc should be 'parspasto'. gridorc is an interactive program to control a grid storage server and its attached cpu. The commands are as follows:


Prints a list of filesystem roots available for your user to spawn.

spawn FSNAME	# or spawndisk FSNAME

The spawn or spawndisk command starts a fileserver for the named rootscore and then begins serving a namespace rooted within it from the cpu server. The spawn command creates a small (100mb) ramdisk to cache fs data, the spawndisk command uses a somewhat larger (1gb) disk partition for temporary data storage. After a successful spawn, the rcpu command to access the spawned environment will be printed. Execute that command in a separate window to use your system.


This command saves a new snapshot of your filesystem. Unless the 'save' command is issued, changes to your fs will NOT be saved, and the save command saves only the changes written to the fs at the time it is issued. If the environment was spawned with 'spawndisk' it must be saved with 'savedisk' not just 'save'. Once an fs snapshot is saved and named, it is immutable - you will always receive the same state for spawning that name. To preserve a change in state, the appropriate version of the save command must be used.


This command adds a user to fs, places them in the sys group, saves a snapshot of the fs, and adds that scorename to that users' available rootscores. Note that the invite-saved snapshot won't be available to the user who created it - an additional 'save' command would need to be issued. Also, the invite command must be used with fses created with 'spawn' and not with 'spawndisk' at the moment.


This command frees the resources associated with an environment. Users are free to allow their environments to persist without being 'boom'ed, but if the server capacity becomes filled, long-running environments might be terminated to make room for new spawns. Users who are creating multiple environments are encouraged to 'boom' them if they are no longer serving an active purpose. The 'boom' command frees the resources of an active environment, it does not delete the associated snapshot, which can always be re-spawned.


The status command lists the currently active environments being provided by the storage+cpu pair. The command


terminates the gridorc. Spawned environments will continue exist and be available until and unless they are boomed.

ndb information

authdom=spawngrid auth=isoauthtest
sys=isoauthtest ip=
sys=fraspasto ip=
sys=fraspacpu ip=
sys=parspasto ip=
sys=parspacpu ip=
sys=njspasto ip=
sys=njspacpu ip=
sys=chispasto ip=
sys=chispacpu ip=
sys=sfspasto ip=
sys=sfspacpu ip=

gridorc script

# user facing grid orchestration helper

while (~ $1 -*){
	case -u
	case -d
	case -h
if(~ $targhost tcp!*)
if not
if(~ $#reqdial 0)
if(! test -e /n/g/
	srvtls $hostdial $targhost.gridsvc.$pid /n/g
if(! test -e /n/g/{
	echo no grid service found at /n/g >[2=1]
echo 'scores | spawn scorename | save oldname newname | invite user scorename | boom scorename | status'
cat /n/g/sto.out &
cat /n/g/sto.err &
cat /n/g/cpu.out &
cat /n/g/cpu.err &

fn killcats{
	@{echo kill>/proc/$catkill1/ctl}
	@{echo kill>/proc/$catkill2/ctl}
	@{echo kill>/proc/$catkill3/ctl}
	@{echo kill>/proc/$catkill4/ctl}

	case exit
	case *
		tlsclient -a $reqdial /bin/echo $usercmd
#		sleep 1
		echo $griduser req >>/n/g/