Developing Websites with Workspaces: Local Tools, Safe Isolation, Real Releases
Modern website development is usually split between two worlds.
On one side, developers want a familiar local workflow: their IDE, editor shortcuts, project search, CSS tooling, JavaScript editing, and the ability to work across multiple files quickly.
On the other side, hosted website platforms need strong boundaries: isolated customer environments, controlled permissions, safe previews, reproducible builds, and a clear separation between development state and live production output.
Workspaces is designed to connect these two worlds.
It allows teams to host and manage websites inside a workspace, including templates, placeholders, data bindings, online shop integrations, and other dynamic site features, while still giving developers a practical way to work with site files locally.
The key idea: developers can work with a site project through a virtual SFTP gateway.
Not raw SSH.
Not direct server filesystem access.
Not uncontrolled FTP.
A controlled, scoped, developer-friendly gateway.
What is a workspace?
In Workspaces, a workspace is the isolated environment for a customer, team, or project.
A workspace can contain one or more sites. Each site has its own project files, configuration, preview flow, build process, and publish state.
This means developers do not work directly on the platform itself. They work inside the allowed site project folders of a workspace.
That distinction is important.
Workspaces provides the hosting, permissions, preview handling, build pipeline, and release management. The developer focuses on the website.
Not “SSH access”, but a virtual SFTP gateway
One important detail should be made very clear:
Workspaces does not give developers a real SSH shell on the server.
There is no interactive shell.
There is no access to arbitrary server paths.
There is no way to browse around the host filesystem.
There is no accidental crossing into other workspaces or platform internals.
Instead, Workspaces provides a virtual SFTP gateway.
Developers authenticate using their SSH public key. The workspace is selected through the SSH username, and the virtual filesystem only exposes the site project folders that the user is allowed to access.
For example:
mkdir -p ~/mnt/workspaces-sites
sshfs -p 2222 <workspace-slug>@<sftp-host>:/ \
~/mnt/workspaces-sites -o auto_cache,reconnect
After mounting, the site becomes available locally:
~/mnt/workspaces-sites/<site-slug>/
That folder can then be opened in VS Code, WebStorm, PhpStorm, or any other editor.
This is important: the mounted folder is the site project source, not the platform source code.
So the developer edits the website, not the application core.
Why this matters
This approach gives developers the convenience of local tooling without weakening the safety model of the platform.
A traditional server SSH account often creates too much power. Even if users are careful, direct filesystem access can become risky in hosted or multi-customer systems. It can expose internal paths, create permission problems, bypass deployment logic, or make it unclear what exactly is live.
The virtual SFTP model avoids that.
Developers get:
- local IDE support
- file search and navigation
- normal editor integrations
- multi-file editing
- CSS, JavaScript, and template work
- a familiar mount-based workflow
The platform keeps:
- workspace isolation
- scoped permissions
- no shell access
- no arbitrary filesystem paths
- controlled write access
- preview protection
- build and release tracking
That balance is the main advantage.
Preparing access
Before a developer can work on a site, a few things need to be in place.
First, the developer adds their SSH public key in Workspaces:
My Account > SSH Keys
Then the required roles or scopes must be assigned.
Typical permissions are:
site:view-dev Allows dev session and preview access
site:files:read Allows reading site files
site:files:write Allows modifying site files
site:build Allows building a site release
site:publish Allows publishing a built release
Not every developer needs every permission.
For example, someone working only on templates and CSS may need file read/write and dev preview access, but not necessarily publish rights. Publishing can remain limited to senior developers, maintainers, or project owners.
The site also needs a bound domain or target host, because preview access is host-bound.
That is an intentional safety feature.
Mounting the site locally
Once access is configured, the developer can mount the virtual site filesystem.
Example:
mkdir -p ~/mnt/workspaces-sites
sshfs -p 2222 <workspace-slug>@<sftp-host>:/\
~/mnt/workspaces-sites -o auto_cache,reconnect
The available sites appear below the mount point:
~/mnt/workspaces-sites/<site-slug>/
Now the developer can open the site folder in their editor:
code ~/mnt/workspaces-sites/<site-slug>/
From that point on, the workflow feels like working on a normal local project.
The difference is that the files are backed by Workspaces and still follow platform rules.
Starting a Dev Session
Write access is not always open.
Before changing files, a developer starts a Dev Session in Workspaces:
SiteManager > Open Site > Start Dev Session
Only then are writes through the online editor or virtual SFTP enabled.
Without an active Dev Session, the virtual filesystem behaves as read-only for modifications.
This prevents accidental edits and makes development activity explicit. It also helps teams understand when a site is currently being worked on.
Opening the preview correctly
Starting a Dev Session is not the same as opening the preview.
The browser also needs a valid preview grant.
A typical preview URL looks like this:
https://www.example.com/?mode=dev
Alternatively, the developer can use the preview handoff link from the SiteManager.
The important part is that preview access is tied to the real site host. This means that a developer previews the site in the same host context in which the site will later run.
That matters for domains, cookies, integrations, asset URLs, shop connections, and data bindings.
The Dev Session controls whether development changes are available.
The preview grant controls whether the browser is allowed to see them.
Both are needed.
Developing with real tools
Once the site is mounted and the Dev Session is active, developers can work in the way they are used to.
For small edits, the built-in online editor is often enough.
For larger work, local IDE access is much better.
Examples:
- editing templates
- adjusting CSS
- changing JavaScript
- working across multiple components
- updating layout fragments
- reviewing multiple files side by side
- using editor search and refactoring tools
Saving files through the mounted folder triggers development events in Workspaces.
CSS changes can often be reflected directly. Other changes may trigger a reload, depending on the type of file and the site setup.
The goal is simple: make hosted site development feel as close as possible to local development, while still keeping the platform in control.
Placeholders, data, and shop integrations
Workspaces sites are not just static files.
Templates can use placeholders and structured content models. They can also connect to real data sources, including online shop data, product information, navigation structures, content entries, and other workspace-managed data.
That means developers should not manually fake production data in random files.
Instead, templates should be written against the actual data model and integrations provided by the site.
A good site project separates:
template structure
styling
client-side behavior
content placeholders
data bindings
shop or application integrations
This makes the site easier to maintain and much safer to publish.
Build first, publish later
One of the most important concepts in Workspaces is the separation between development files, builds, releases, and live publishing.
Publishing does not simply expose the current development file state.
Instead, the workflow is:
Develop
Preview
Build
Review release
Publish
A build creates a release snapshot.
Publishing makes a built release live.
This gives teams a much better deployment model than “save a file and hope production still works”.
It also creates a clearer audit trail:
What was changed?
When was it built?
Which release was reviewed?
Which release went live?
For professional site operations, this distinction is essential.
Online editor or local IDE?
Both workflows have their place.
The online editor is ideal for:
- quick text changes
- small content corrections
- simple template adjustments
- low-risk edits
The local SFTP/sshfs workflow is better for:
- multi-file changes
- template development
- CSS work
- JavaScript changes
- component updates
- larger layout changes
- developer-heavy tasks
There is one important difference: conflict handling.
The online editor can use stronger request-level conflict protection, for example through mechanisms such as ETag and If-Match.
SFTP is more convenient for developers, but it is naturally weaker when it comes to detecting simultaneous edits.
So teams should be clear about who is working on which site and when.
A simple rule works well:
Use the online editor for small, isolated changes.
Use local IDE access for real development work.
Build a release after every meaningful completed state.
When to use Git
The Workspaces SFTP workflow is for website project work.
It is not a replacement for the normal source code repository of the platform itself.
Use the regular Git repository for changes to:
- platform code
- generator logic
- APIs
- controls
- system components
- deployment infrastructure
- shared application behavior
Use the Workspaces SiteManager workflow for:
- site templates
- site-specific CSS
- site-specific JavaScript
- content layout
- presentation logic
- placeholder-based rendering
This separation keeps platform development and site development from being mixed together.
That makes the system easier to understand, safer to operate, and easier to scale across multiple workspaces and websites.
A practical developer workflow
A typical Workspaces development flow looks like this:
1. Add SSH public key in Workspaces
2. Confirm required site permissions
3. Mount the virtual SFTP filesystem with sshfs
4. Open the site folder in the local IDE
5. Start a Dev Session in SiteManager
6. Open the host-bound preview
7. Edit templates, CSS, JavaScript, and site files
8. Review the result in preview mode
9. Start a build
10. Check the build output and release
11. Publish the reviewed release
That flow gives developers speed without giving up control.
Why this is a good fit for hosted site development
The strongest part of this model is that it does not force a compromise between developer experience and operational safety.
Developers do not have to edit large templates in a browser-only interface.
They can use their own tools.
At the same time, the platform does not need to expose shell accounts, server paths, deployment directories, or cross-workspace filesystems.
The result is a clean middle ground:
Local development experience
+
Hosted platform safety
+
Preview control
+
Build and release discipline
For teams building and operating websites in Workspaces, this creates a workflow that is both comfortable and reliable.
It feels familiar to developers.
It remains safe for administrators.
And it gives project owners a clear path from change to preview to release to production.
That is exactly what a modern website workspace should do.
Top comments (0)