+code

Your +code is used for access to your urbit, generally via web interfaces and mobile clients. Some application providers call it a "luscode", while others call it an "access code". It is an eight-syllable phenome, like ~ropnys-batwyd-nossyt-mapwet. Not to be confused with a master-ticket.

|hi ~zod 'optional message'

Running |hi is Urbits most basic p2p messaging affordance and offers a quick and reliable way to see if you have a direct connection to a peer. If you are connecting to a ship for the first time you may get a message in the dojo like ~zod is your neighbor.

|install ~dister-hoster %some-app

If you know the name of the app, and the @p of the ship distributing it, |install is the most direct way to get new apps. You can also visit <your-domain>/apps/landscape and click the Get Apps button to discover apps.

|nuke %some-app, =desk &

Running |nuke will destroy, or 'nuke', all the state relating to that application. This is an irreversible action, so ensure you know you want to delete any related data. It is effectively a factory reset of that application, but it can have unintended consequences if done haphazardly.

|uninstall %some-app

The |uninstall command is slightly unintuitive. Typically you might expect that it wipes any app data, similar to |nuke, but technically it archives app data and stops all microservices, or 'agents', relating to the app. It is possible to recover this state by reinstalling the app.

+vats %some-app

The +vats command can be run without any arguments and will print out the metadata of all the apps, or 'desks', currently on your ship. If you provide the name of %some-app, it will print out only the metadata for that app. Particularly helpful elements of this data include:

• %cz hash - helpful to know what version of an app you are on, developers or support will often ask for this info to figure out if you are encountering a known issue.
• app status - helpful to know if the app is suspended or running, which may impact intended functionality
• publishing ship - desks of the same name can be distributed by different ships, and may offer different functionality, e.g ~ridlyd might distribute a version of %gora that is cross-compatible with %gora from ~talwet, but which offers a different front end client.
• pending updates - Will let you know if there is an issue getting updates due to kernel version incompatibility

|bump

Occasionally, you will have an app on your ship that has not been updated by it's developer in some time, and an inbound kernel upgrade will conflict with this existing application. Running |bump will apply the kernel update and suspend any incompatible desks in the process.

|ota ~sampel

Another common reason for not getting commands can come from having a derelict sponsor, or otherwise having a poor connection with your 'Over The Air' (OTA) update provider. You can chose an alternative provider for your kernel updates by running |ota and providing the @p of a valid ota provider as an argument. You can get OTAs from any ship, but by default you get them from your networking sponsor.

|start %some-app %some-agent

Use |start to manually start a specific agent on a desk, defining first the desk name and then the agent name

|suspend %some-app

Alternatively, you can |suspend to stop all agents on a desk.

|pause %some-app

The |pause command prevents a desk from receiving updates from the app distributor. This can be helpful for freezing an app from receiving any undesired changes. Take that, MEGACORP SaaS.

|revive %some-app

Running |revive restarts previously suspended agents for a given desk.

+azimuth/block

Check which Ethereum block your ship has processed with +azimuth/block. This can be helpful to compare against other sources, e.g. Etherscan, to ensure that your ship understands the current height of the ethereum blockchain and any attendent Azimuth state.

-azimuth-load

If your Azimuth state is out of sync, use -azimuth-load to refetch a snapshot and catch you up to the current state of the Azimuth.

Both the urbit dojo and the Vere runtime are capable of handling commands for managing your urbit's memory consumption and loom size.

Use |mass or ./urbit mass to print a memory report showing where your loom space is allocated. Run |meld (or ./urbit meld) to deduplicate memory—this can reduce usage by up to 50% but takes time. For faster compression with smaller gains, use |pack. These operations help keep your ship running smoothly, especially on resource-constrained systems.

From dojo:

|mass

|meld

|pack

From runtime (ship offline):

./urbit mass /path/to/pier

./urbit meld /path/to/pier

./urbit pack /path/to/pier

These can also be run from a 'docked' pier, using the following syntax:

./path/to/pier/.run <command>

|moon

Azimuth-based identities can use |moon to generate a new moon identity, linked to it's parent identity. The command returns a keyfile you'll use to boot the moon.

|moon-breach ~sampel-sampel-palnet

If your moon gets into a bad state, |moon-breach performs a factory reset.

|moon-cycle-keys ~sampel-sampel-palnet

The |moon-cycle-keys command updates your moon's cryptographic keys—useful for security or recovery purposes.

+sponsor

This command will print out the @p of your ship's current sponsor. This is helpful for troubleshooting connectivity issues, as if there is a ship in your sponsorship hierarchy that is offline, it can result in difficulty finding new network piers. You can also check the Network Explorer to retrieve this information, but it is important to note that because Urbit is a distributed system, it is possible that your ship has a different understanding of it's sponsorship chain, particularly if you just executed onchain identity management actions, e.g. changing your sponsor in Bridge.

From dojo:

|exit

Or press Ctrl-D

Use |exit or Ctrl-D to gracefully shut down your running urbit. While you should try to shut down gracefully to ensure your urbit's state is properly persisted, one of Urbit's affordances as a 'solid state interpreter' means that it technically has no internal conception of being on or off. It's state is a pure function of it's input events, and those need to be recorded before an atomic update of your state. So while an elegant shutdown is ideal, incidents such as power loss are straightforward to recover from.

./urbit /path/to/pier

You can start your urbit by running ./urbit followed by your pier name (e.g., ./urbit sampel-palnet).

./path/to/pier/.run

That said, typically after first boot in modern runtimes, your ship should have auto-'docked' (put a copy of the runtime in it's own pier), such that you can use ./path/to/pier/.run to restart. This can also take any of your regular runtime arguments, like meld or --loom 32.

Typically, when using modern versions of the Vere runtime, if you have ever elegantly shut down your Urbit, it should have gon through an auto-'docking' process. If trying to start your urbit using ./path/to/pier/.run doesn't work, try manually docking:

./urbit dock /path/to/pier

The dock command copies the current vere runtime binary into your pier. This makes your pier self-contained with a specific runtime version, which is useful for version pinning or ensuring your urbit can run independently of system-level vere installations.

./urbit --loom 32 /path/to/pier

The loom is your urbit's memory space. Use the --loom flag with a power-of-two exponent: 30 for 1GB, 31 for 2GB (default), 32 for 4GB, or 33 for 8GB. Larger looms allow for more apps and data but will consume more available RAM. Choose based on your available system resources and usage needs.

While your urbit's state needs to fit in the available loom, your pier also includes the event log for your ship, which includes every piece of data that has ever been sent to your ship. This is an 'append-only' ledger, but in practice holding on to every event you've ever been sent is often unnecessary and unwieldy. The Vere runtime has tools for creating checkpoints and truncating this event log. You must shut down your ship before truncating your event log.

To create a new 'epoch', a discrete event log segment, you can use roll:

./urbit roll /path/to/pier

and you should see an output that ends with something like disk: created epoch 5886.

After creating a new epoch, you can use chop to delete old epochs:

./urbit chop /path/to/pier

This will discard all but the two latest epochs. If you have only two epochs, it will do nothing. If you have never run chop before, this can significantly reduce the size of your pier on your host OS. Ships used for many years can be reduced from 100s of GBs to <10GB.

./urbit next /path/to/pier

Use ./urbit next to automatically check for and install the latest vere runtime for your pier. Regular runtime updates ensure you have the latest performance improvements, bug fixes, and networking affordances.