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.
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. An in-place self-serve upgrade is not automated yet, so our team arranges it with you:
- Ask support (portal chat or support@openboxes.cloud) to move you to Dedicated
- A dedicated database and instance are provisioned for your account
- Your data is migrated from the shared schema to the new database at a time agreed with you
- Your instance restarts on the dedicated infrastructure
Your instance is briefly unavailable during the cutover; we schedule it for your off-hours and confirm the expected window with you beforehand.
What carries over:
- All OpenBoxes data (products, locations, shipments, orders, users)
- All configuration and settings
- Your subdomain URL (no change)
Dedicated to Enterprise#
This upgrade is seamless because both tiers use dedicated infrastructure:
- 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
- No downtime or data migration required
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 — 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 (announced on the status page). 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: for a scheduled OpenBoxes version upgrade on the Shared tier, the advance email to the account owner is approved for sending at least three days before the window starts and goes out shortly after approval. It states the date and time — the subject line in UTC, and the email itself in your instance's time zone (the platform default, US Eastern, unless one has been set for you) with the UTC time alongside — how long you are affected and when, what's new in the release with a link to the release notes, and which instance is affected. Emergency maintenance can be approved inside that three-day floor, but only with a recorded reason, and the email says the notice is shorter than usual and why. There is no opt-out for these notices — they are transactional, 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. Once your advance notice has been sent, the window is closed out: you receive a follow-up email if it is postponed or cancelled, and a completion notice when the upgrade finishes. The status page shows the window and its progress throughout — one entry for the whole window.
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 get an advance email, postponement or cancellation notices, and a completion notice exactly as a Shared customer does, with the same notice period — 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, and the completion notice reports the same single measured offline span. Nothing is deleted, and your data is not changed.
- Requests get a bare
503, with noRetry-Afterand no JSON body. Your address stays routable while the instance is stopped, so the site and the API both answer503 Service Unavailable— with no maintenance page, noRetry-Afterhint and no machine-readable body. Treat any503inside the announced window as retry-after-the-window: the advance email is where the timing comes from, because the response itself carries none. Do not parse the body or readretryAfterSeconds; neither is there. - 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 carries the same Dedicated carve-out.
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.