NabWP includes developer-oriented workflows, and access to command-line or version-control tools depends on the selected plan, account permissions and enabled environment. Our product information describes SSH, Git and WP-CLI capabilities, while the WordPress Manager provides supported website tools within the scope of the selected installation. Confirm the access shown for your service before planning a deployment around a particular command.
IN THIS ARTICLE
01 Work within the available command-line access
WP-CLI is useful for supported WordPress management tasks, such as inspecting installed plugins, checking the installation or carrying out an appropriate maintenance operation. The command interface in the workspace applies restrictions and does not accept every possible WP-CLI argument. A restricted command should not be treated as an invitation to bypass the account's controls.
Where SSH is available, it operates with the permissions granted to the hosting account. It does not mean unrestricted root access to the entire server or access to other customers' websites. Tell our team if a project requires server-wide services, special system packages or a runtime outside the available environment so that suitability can be checked first.
02 Plan code deployment and protect website data
Git can help track code changes where the relevant tools are available, but a code repository is not a complete backup of an active WordPress website. Database content, orders, uploads and external service configuration may need separate handling. Define what your deployment changes and what must remain on the live site.
Use staging and a current backup for significant work, and verify the result after deployment. Our WordPress AI Engineer can help investigate or perform supported technical tasks through its available tools. Provide the goal, the affected website and the expected outcome, then review the proposed changes. This gives experienced developers a useful working assistant while preserving a clear boundary around the account and website being managed.
03 Example: begin an SSH session with a site identity check
Where your service provides authorised SSH and WP-CLI, start with the verified installation path and intended URL. Replace the account and directory placeholders rather than relying on whichever folder the shell happened to open.
wp --path='/home/ACCOUNT/sites/example.com' \
--url='https://example.com' core version
wp --path='/home/ACCOUNT/sites/example.com' \
--url='https://example.com' option get homeConfirm the returned home address belongs to the selected website and record whether the installation is live or staging. These inspection commands do not request an update. The Manager’s restricted command interface can allow fewer options than a normal SSH session, so use only the access actually provided.
Expected result: You know the installation and WordPress version before planning a change. Git can then track the relevant code, while a separate backup strategy protects database content and uploads. Neither SSH nor WP-CLI implies server-wide root access.
What should I check before using SSH or WP-CLI with NabWP?
- Open the available terminal, Git or WordPress command tool for the selected site and confirm its current working scope.
- Start with a read-only inspection and use an appropriate test environment for a significant code or database change.
- Record the release and recovery method, then verify the resulting WordPress function rather than relying only on command success.
The WordPress command interface can restrict allowed arguments, and browser terminal access depends on the service. Neither implies root privileges. Git protects tracked code history, while uploads, database records and other live data need their own backup strategy. The Engineer's supported file Undo does not cover arbitrary shell commands.