Instance Management

Your OpenBoxes instance is the core of your Lift account. From the Instance section of the portal, you can monitor its status and control its lifecycle; backups have their own Backups page in the sidebar. On the Dedicated plan the Instance page also carries the Staging copy card. See Staging Copies.

Instance Status#

The portal displays your instance status with a color-coded indicator. Here is what each status means:

Status	Indicator	Description
Running	Green	Your instance is live and accepting connections
Starting	Blue (pulsing)	Your instance is booting up (typically 1-2 minutes)
Provisioning	Blue (pulsing)	Initial setup in progress (first time only, 2-5 minutes)
Stopped	Gray	Your instance is shut down and not accessible
Maintenance	Yellow	A platform update or migration is in progress
Error	Red	Something went wrong. Contact support

When your instance is Running, you can launch OpenBoxes directly by clicking the Launch button or visiting your subdomain URL.

Starting and Stopping Your Instance#

You can stop your instance when it is not in use and start it again when needed.

Stopping#

Go to Instance in the portal sidebar
Click Stop Instance
Confirm the action

When stopped:

Your OpenBoxes instance is not accessible
Your data is fully preserved
No usage is accumulated

Starting#

Go to Instance in the portal sidebar
Click Start Instance
Wait for the status to change to Running (typically 1-2 minutes)

Your instance comes back with all data intact, exactly as you left it.

Subdomain Configuration#

Every Lift instance gets a custom subdomain:

https://your-company.openboxes.cloud

Choosing a Subdomain#

You select your subdomain during signup. Subdomains must be:

Between 3 and 50 characters
Lowercase letters, numbers, and hyphens only
Cannot start or end with a hyphen
Unique across all Lift accounts

Changing Your Subdomain#

Subdomain changes are not self-service after provisioning; there is no rename option in the portal. If you need a different subdomain, contact support at support@openboxes.cloud and we will look at what is possible for your account.

Instance Details#

The Instance page shows key information about your deployment:

Detail	Description
Subdomain	Your instance URL
Tenant ID	Your account's identifier, useful when contacting support
Region	Data center location (`us-east1`)
Tier	Current subscription tier
Version	The version of OpenBoxes running on your instance
Created	When your instance was first provisioned
Last accessed	When someone last launched OpenBoxes
Response time	The latest response time measured by the platform's health check

Upgrading Tiers#

When your organization outgrows your current plan, start from Upgrade plan on the Billing page. Here is what happens to your instance during each upgrade path.

Shared to Dedicated#

This is the most significant upgrade because your data moves from a shared database to a dedicated one. It is not self-serve: our team arranges it with you.

Ask support (portal chat or support@openboxes.cloud) to move you to Dedicated
Your billing moves to the Dedicated plan when the change is placed
Our team stands up a dedicated database and instance for your account
Our team moves your data from the shared schema to the new database and emails you to agree a cutover window
At the agreed window your instance is switched over to the dedicated infrastructure, on the same web address

Your instance is unavailable during the cutover. We agree the window with you by email before it happens, and we will work to your hours wherever we can.

What carries over:

All OpenBoxes data (products, locations, shipments, orders, users)
All configuration and settings
Your subdomain URL (no change)

Dedicated to Enterprise#

Both tiers already run on dedicated infrastructure, so there is no data move between hosting tiers. The change is arranged with our team as part of your Enterprise contract:

You work with our sales team to set up your Enterprise contract
Enterprise terms (resources, support arrangements, and any per-agreement capabilities) are applied to your account
Enterprise runs on its own server, so our team schedules that move with you the same way as any other

Backups#

Lift backs up your data automatically on every plan, but the mechanism differs by tier:

Plan	Scheduled Backup	Retention	Scheduled Backups Listed on the Backups Page	On-Demand Backups
Shared	Nightly (around 02:15 UTC), taken by Lift	30 days (90 days or 1 year with a retention add-on)	Yes	Yes
Dedicated	Nightly (04:00 UTC), taken by the database operator	30 days	No, only on-demand backups appear there	Yes
Enterprise	Every 6 hours, with copies kept in a second region (configured at onboarding as part of the agreement)	90 days	No, only on-demand backups appear there	Yes

If you are on Dedicated or Enterprise and need to restore from a scheduled (operator-level) backup, contact support; self-serve restores on the Backups page cover the backups listed there.

Backups older than your plan's retention period (30 days on Shared and Dedicated; 90 days under an Enterprise agreement) are removed automatically. The Backups page in the portal sidebar lists every backup with its status, size, and a download option once it is ready.

Keeping Backups for Longer#

On Shared you can extend retention with an add-on under Billing > Add-ons, once your subscription is paid: 90 days for $15/mo ($144/yr) or 1 year for $30/mo ($288/yr). You hold one or the other, not both. The Backups page shows the period that is in force.

A longer retention changes how far back your backups go, not how recent the newest one is: a nightly backup can still be up to 24 hours old. The full period accrues from the day you add the add-on: backups already deleted do not come back, and a year of history exists a year later. And because every backup is kept for the whole period, a record you delete from your instance remains inside those backups until they age out.

Retention add-ons are not sold on Dedicated today; Dedicated backups are kept 30 days. Enterprise agreements carry their own 90-day retention.

On-Demand Backups#

To take a backup right now (for example, before a large import or a yearly stock count):

Go to Backups in the portal sidebar
Click Run backup now (the button is disabled while a backup is running)
Wait for the new row to show as complete

Only one backup runs at a time; the button is disabled while a backup is in progress. On-demand backups follow the same retention as scheduled ones.

Restore from Backup#

The account owner can restore any listed backup from the portal, with no support ticket needed:

Go to Backups in the portal sidebar
Open the ⋯ menu on the backup you want
Choose Restore from this backup…
Type your subdomain to confirm, then start the restore

A restore is destructive: it replaces your instance's current data with the snapshot, and anything entered since that backup was taken is lost. Take an on-demand backup first if you might need the current state back. Only one restore can run at a time (the Restore option is disabled while another restore is in progress), and the page shows the last restore's status and a history of previous restores.

OpenBoxes Version#

Lift manages the OpenBoxes version for you. Every instance runs the release we have validated for the platform (your Instance page shows which one), and we roll updates out fleet-wide in a way that minimizes disruption. You cannot pick or pin a specific OpenBoxes version; the version shown on the Instance page is informational.

Maintenance Timing#

Routine platform maintenance (security patches, infrastructure upgrades, and platform improvements that do not touch the OpenBoxes version itself) normally lands inside the weekly maintenance window of Sundays 02:00–04:00 US Pacific. For Dedicated customers we do our best to coordinate timing around your operations; Enterprise agreements include version upgrades in a window you choose, rehearsed on a copy of your data first.

An OpenBoxes version upgrade is different: it is not tied to that weekly window. Each upgrade gets its own individually announced maintenance window, with the advance notice described next in "Advance Notice."

Advance Notice#

Continuing from "Maintenance Timing" above: before a scheduled OpenBoxes version upgrade on the Shared tier, our team emails the account owner in advance with the date and time of the window and roughly how long you are affected. These notices are written and sent by our team rather than generated automatically, so there is no fixed minimum notice period; emergency maintenance may come with shorter notice than usual, and the email says so. There is no opt-out for these notices. They are service messages, not a subscription you can turn off.

Shared plan. During the window your instance is read-only for a span (you can look around, but saving is paused) and briefly unavailable right at the end while the upgrade finishes; nothing is deleted, and the platform rolls back automatically, leaving your instance unchanged, if a problem is found during verification. That is how the whole fleet moves today: one window for everybody. If the window is postponed or cancelled, our team emails you again. Scheduled windows are not listed on the status page today, so the advance email is where the timing comes from.

When your advance notice names a window for your instance specifically. We are moving to upgrading instances one at a time, and your advance email is what tells you that it applies to you: it names a slot for your instance, with its own start and finish, inside the wider announced window. Three things differ then.

Your instance is read-only for its own slot and is never taken offline. Pages keep loading, saving and signing in are paused, and there is no unavailable pause at the end.
How long depends on how much data your instance holds: most instances are read-only for well under an hour; the largest can take up to about ninety minutes. Your advance email quotes your instance's own figure and its own expected start and finish, never the fleet's total, which covers every instance in turn and can run for several hours.
You will be signed out twice: once when your instance moves across to the upgraded servers, and once more in a short, separately announced window when we move it back onto its usual servers. Your data is not touched and the instance stays writable throughout that second move.

Dedicated instances#

A Dedicated instance is upgraded on its own, and its window is not a smaller version of the one above. You are told about it by email in advance, and again if it is postponed or cancelled, exactly as a Shared customer is, but three things differ, and each one is load-bearing:

The instance is stopped for the whole window: fully offline, not read-only for a span. A Shared instance stays readable while saving is paused; a Dedicated one is stopped for the length of the window. The advance email quotes one number, the whole window, rather than a read-only span plus a short outage at the end. Nothing is deleted, and your data is not changed.
The API answers 503 with Retry-After; the site answers a bare 503, with no Retry-After and no JSON body. Your address stays routable while the instance is stopped. During your instance's own upgrade window the API answers 503 with Retry-After, and pages opened in a browser get 503 Service Unavailable with no maintenance page. The API's code may be MAINTENANCE_WINDOW or UPSTREAM_UNAVAILABLE; inside the announced window either one means the window. There is no need to contact support. Treat any 503 inside the announced window as retry-after-the-window: the advance email is where the timing comes from, because Retry-After is a pause between attempts, not the end of the window.
The window is not on the public status page. It is your maintenance, not a platform event, and publishing it would tell every status-page visitor that your company is being upgraded and when. You are told by email instead.

If you use the API, see Maintenance Windows. The exact 503 response and retry guidance there describe the Shared contract, and that page's Dedicated section says which of its codes a Dedicated instance returns in its window.

Troubleshooting#

Instance stuck in "Provisioning"#

New instances typically finish provisioning within 5 minutes. If your instance has been provisioning for more than 15 minutes, contact support.

Instance shows "Error" status#

This usually indicates a temporary infrastructure issue. Try clicking Restart Instance. If the error persists, contact support with your instance details.

Cannot access instance after starting#

After clicking Start, wait for the status to show Running (1-2 minutes). If the instance shows Running but you still cannot access it, try clearing your browser cache or using an incognito window.