Variables are available in fields that support them. These fields are marked with a variables icon, and variables are written inside double curly braces, for example {{base_url}}.

Insert a variable into a field​

In a field that supports variables, type {{ or press Ctrl+Space to open variable suggestions. The picker shows available variables and their current values.

A variable that does not exist is shown in red. If a variable's value is overridden by a higher-priority scope, the lower-priority value is shown as crossed out. This helps explain which value PacOS will use.

Variables can be used in any field that supports them, not only in the Mock Server plugin.

Variable scopes​

PacOS has several variable scopes. They differ in where a variable is available and whether another scope can override it.

1. System variables​

System variables are configured in Application → Settings → System → Variables. Their names always start with a dollar sign, such as $current_date or $random_name.

System variables use a JavaScript engine. A variable can return a fixed value or calculate one when evaluated. For example, a date variable can return the current date, while another variable can generate a random name or year.

System variables have global availability, but they are the lowest-priority scope: a variable with the same name from a higher-priority scope can override its value.

2. Plugin variables​

Plugins can define their own variables for use within the plugin. Their scope is limited to that plugin.

For example, Mock Server supports variables associated with a collection of mocks. These variables are available within the selected collection and can provide values used by its mock scripts.

3. User variables: Global and collection variables​

User variables are managed in the Variables module. They are divided into two groups: Global and named collections.

Global variables are available continuously. They are useful for values that usually stay the same while you work, such as a service URL or a user-specific setting. Global user variables override plugin variables and system variables with the same name.

Collection variables belong to a named user collection. Only one user collection can be active at a time. Switching the active collection reloads its variables throughout the system.

For example, one collection might define myVariable as one, while another defines the same variable as notMyVariable. Switching collections changes the value supplied by that collection without requiring you to edit every field that references it.

Collection variables override plugin variables and system variables with the same name. Global user variables have higher priority than collection variables.

Which value wins when names overlap?​

When variables with the same name exist in multiple scopes, PacOS resolves them by priority. From lowest to highest, the order is:

1. System variables
2. Plugin variables, such as variables belonging to a Mock Server collection
3. User collection variables from the active user collection
4. Global user variables

The highest-priority enabled variable with a matching name supplies the effective value. For example, if a system variable and a user collection both define base_url, the collection value takes precedence. If a global user variable also defines base_url, the global user value takes precedence over both.

You can temporarily disable individual global or collection variables. Disabled variables are not offered as available variables in the variable suggestion window.

The Variables module includes a help window that can be used to inspect how the resolution and override rules work.

Switch collections or override values while working​

You do not need to open the Variables module every time you want to change the active context. PacOS provides quick access from the application bar and icon {v} to switch the active collection or temporarily override a variable's current value.

The variable plugin's help explains that the active collection is reloaded throughout the system and that global variables with the same name are overridden by variables from the active collection. For variables that can also be overridden by higher-priority scopes, the suggestion window helps you see the effective value and which values are shadowed.

Copy, paste and share variables as JSON​

The Variables editor supports copying and pasting variable data in JSON format. It detects the format and imports or exports variables through the clipboard. When you paste JSON into the Variables window, the entries are added to the collection currently being edited. This makes it practical to share values for a test scenario: one team member can send the JSON to another, who can paste it into the appropriate collection. Anyone who imports the same values can activate that collection to change the behaviour of extensions that use those variables.

For example, this JSON defines two variables:

{
  "exampleVariable": "current example value",
  "exampleNumber": "15"
}

Paste the JSON into the Variables editor while editing the collection that should contain these values. The variables become available according to the normal scope and override rules. In this example, both values are strings, including "15".

Check the contents before importing shared JSON, especially if it contains sensitive values.

Use variable collections to switch test scenarios​

Variable collections can be more than a convenient place to store related values. When a plugin uses variables in its fields or scripts, a collection can supply the data for a particular test scenario. Switching the active collection then changes those inputs without requiring you to edit every mock or request.

For example, a Mock Server script can use a variable for the response body. One collection could provide a successful response, while another provides an error response:

{
  "responseBody": "{\"status\":\"ok\",\"items\":[]}"
}

An error-scenario collection could use the same variable name with a different value:

{
  "responseBody": "{\"status\":\"error\",\"message\":\"Service unavailable\"}"
}

If the mock's script assigns response.body from {{responseBody}}, activating the relevant collection changes the body returned by that mock. The script and mock configuration can stay the same while the scenario data changes. The exact response still depends on how the plugin script uses the variable and on the response configuration.

The same idea can apply to an HTTP request plugin: if its URL, headers, request body or other supported fields use variables, a collection can provide different inputs for different scenarios. For example, one collection could target a test endpoint and another a staging endpoint, or provide different request bodies. This only works for fields and behaviours that the plugin actually supports through variables.

Collections can therefore act as shareable test contexts. A team can prepare values for normal, error, empty-result or boundary-condition scenarios, export them as JSON, and import them into the corresponding user collection on another PacOS instance. After importing, the user activates the collection to apply its values wherever compatible plugins reference them.

Example: Use variables to switch a mock response​

Suppose a Mock Server script selects a configured response based on a variable. One active collection can provide values for a normal scenario, while another provides values for an error scenario. The same script can then select a response such as HTTP 200 or HTTP 404 based on those values.

This is one example of how variables can change application behaviour without editing each field or script every time. For details on configuring mock definitions and scripts, see Share REST and SOAP Mocks Across Your Team with PacOS.

Practical notes​

• Use system variables for reusable values or JavaScript-generated values that should be available globally.
• Use plugin variables for values that should remain local to a plugin or one of its collections.
• Use user collection variables for switching between named sets of values.
• Use global user variables for user-specific defaults that should remain available while you work.
• Avoid reusing the same name across scopes unless you intend to rely on the override rules.
• Be careful with secrets: variable values may be visible in the UI and should not be treated as a secure secret store.

Try PacOS · Open the demo

PacOS includes a Mock Server plugin based on WireMock. It adds a graphical interface for working with mock definitions and supports REST and SOAP services. Install it during PacOS setup or later from the in-app App Store.

Work on mocks together​

The PacOS interface supports real-time collaboration. When one team member makes a change, other people using the plugin see the update without having to manually exchange configuration files.

This is useful when a developer is adjusting a response while a tester exercises the application, or when several people need to investigate the same integration scenario. It does not remove the need to coordinate changes, but it makes the current mock configuration visible to the team in one place.

Configure REST and SOAP responses​

The plugin is based on WireMock and supports mock definitions for REST and SOAP, including SSL for both variants. You can configure request paths, methods and responses through the interface, then use the mock endpoint from the application or test environment.

For a basic mock, a request can return a configured response. When the scenario needs more flexibility, JavaScript scripts can inspect request data and change the response. A script can also select another response that has already been configured for the mock.

Use JavaScript to select or modify a response​

Scripts have access to the incoming request and the outgoing response. For example, a script can check the request URL and either select a named response or set the response body:

if (request.url.includes({{myVariable}})) {
    response.setResponseByName({{okResponseName}});
} else {
    response.body = {{myVariable}};
}

The {{...}} expressions in this example are PacOS variable placeholders, not ordinary JavaScript string literals. Define the referenced variables in PacOS before using the script. In this example, a matching URL selects a configured response by name; otherwise the response body is set from the variable value.

This makes it possible to model different business scenarios without creating a separate static mock for every case. Use scripts carefully and test the relevant request paths and response outcomes.

Change mock behaviour with variable collections​

PacOS variables can change mock behaviour without requiring you to edit the script every time. There are two different concepts to keep separate:

• Mock Server collection variables belong to a collection within the Mock Server plugin. They are local to that plugin collection.
• User variable collections are managed in the PacOS Variables module. You can switch the active user collection to provide a different set of values across plugins.

For example, a script could use {{responseBody}} when setting a mock response body. One active user collection might define responseBody as a successful response, while another defines it as an error response. Switching the active user collection changes the value supplied to the script, provided no higher-priority variable overrides it and the script uses that value for the response.

User collection variables override Mock Server collection variables with the same name. Global user variables have higher priority than user collection variables. System variables have the lowest priority. The script determines how the effective value affects the response.

For a full explanation of variable scopes, precedence, and editing workflows, see Understanding Variables in PacOS.

Switch collections and override values during testing​

The Mock Server plugin includes a window for managing variable collections. You can switch the active collection when you need to test another set of conditions.

The built-in Variables module can be used to manage user variables. PacOS also provides quick access from the application bar to switch the active collection or temporarily override a variable. System variables are configured separately in PacOS settings.

These options are useful when a test needs to move between normal and error cases—for example, switching from a successful response to a not-found response—without repeatedly editing the mock script itself.

Keep the setup useful and predictable​

Mocking is most useful when the team understands which scenario is active and what each response represents. Give collections and variables clear names, keep response definitions understandable, and verify that a script selects the intended response for each relevant request.

Because multiple people can edit the same mocks, coordinate changes when testing depends on a specific response. And as with any test service, make sure the mock endpoints and any configured SSL settings fit the environment where they are exposed.

A shared place to manage test responses​

PacOS brings mock definitions, scripts and variable controls into one interface based on WireMock. It is useful when a team needs to adjust REST or SOAP responses together and switch between scenarios without requiring every participant to edit configuration manually.

Try PacOS · Open the demo

G-Logger is a PacOS plugin for opening and working with log files in the browser. You can install it during PacOS setup or later from the in-app App Store.

Open a log file​

G-Logger works on its own. Choose a file from the locations available to PacOS and open it in the viewer. You do not need Explorer just to select and read a log.

The file still needs to be accessible inside the PacOS container. Mount the relevant directory into PacOS and make sure its permissions are appropriate. Installing the plugin does not grant access to files that have not been exposed to the container.

Inspect large files without loading everything at once​

Large log files can be awkward to inspect with tools that try to load or transfer the entire file before showing its contents.

G-Logger uses the File Viewer for Vaadin add-on, which indexes files and streams content on demand. Once the file has been indexed, you can navigate to available lines without waiting for the whole file to be transferred to the browser. This is useful when the error you are investigating happened much earlier than the latest log entries.

Search and follow several logs​

G-Logger supports searching within a file, following changes as a file grows, and periodically refreshing the view. It also allows multiple tabs to stay open at once.

For example, while reproducing an issue, you can keep the application log and logs from related services open side by side, then search for the same request ID or error message without switching between terminal sessions.

Use it with Explorer​

You can use G-Logger by itself, but it also works well alongside PacOS Explorer.

Explorer helps you browse mounted directories and manage files. G-Logger is the specialized viewer for reading, searching and following log files. Use Explorer when you need to find or manage a file, then open it in G-Logger to investigate its contents.

See the guide to managing files across Docker containers with Explorer for the volume setup and file-management workflow. Both plugins can be installed from the PacOS App Store.

Give teammates access to the logs they need​

Sometimes a tester or developer needs to inspect a log but does not need shell access to the container. A browser-based viewer gives them a simpler way to read files that the PacOS instance is configured to expose.

This is not a replacement for centralized logging or an observability platform. It is useful when logs already exist as files and you want a straightforward way for the team to inspect them from one place.

Mount only the directories that are needed, review whether they should be writable, and secure access to PacOS. Anyone who can use the viewer may be able to see the contents of the files exposed to that instance.

Try PacOS · Open the demo

The PacOS Database plugin offers another option: configure database connections in PacOS and access them through its browser-based interface. If PacOS can reach databases running in other containers or elsewhere on the network, it can provide a single place to connect to them—without requiring every team member to install a separate database client.

One place for databases across environments​

PacOS can connect to databases that are reachable from the PacOS environment and for which a suitable driver and connection configuration are available. This can include databases running in other containers, provided the network and database settings allow the connection.

That means PacOS can reflect the database access available to it and make those connections available through one interface. It does not bypass network boundaries or database permissions: the PacOS environment still needs network access, and the database must accept the configured connection.

Configure drivers and connections separately​

The plugin separates driver configuration from connection configuration:

1. Configure the database driver and provide the required driver files and settings.
2. Create a connection that uses that driver, including the relevant authentication and connection details.
3. Check the connection to validate the configuration.
4. Save the configuration and open the database in the Database plugin.

Drivers run in isolated classpaths. This design allows the plugin to work with different database engines when an appropriate driver is available, rather than limiting connections to a fixed list of database products.

Browse the schema and run SQL​

After adding a connection, you can refresh its schema when the database type supports schema discovery. The plugin can show available tables and provide table-aware SQL suggestions for supported database engines. You can then open an SQL console for the selected connection and execute queries.

Schema prefetch and table-aware suggestions are currently supported for:

• Oracle
• PostgreSQL
• SQLite
• HSQLDB

Other databases may still be usable through a suitable driver and valid connection configuration, but the same schema browser and SQL suggestions are not currently guaranteed.

Connection and transaction handling​

Connection validation and the underlying handling of connections and transactions are established parts of the plugin. This makes the plugin useful for routine access to test databases from the PacOS environment, without asking every tester or developer to set up a separate client locally.

As with any database client, access depends on the privileges of the configured database account. Use appropriate credentials and grant only the permissions required for the task.

Current limitations​

The Database plugin was one of the first plugins developed for PacOS, and parts of its user interface still need refinement. Its current limitations include:

• Each SQL console is tied to the database connection selected when it was opened.
• SQL editor contents are not retained as session history when the plugin is restarted. Queries that have not been saved elsewhere may be lost.
• Schema browsing and table-aware suggestions are currently available only for Oracle, PostgreSQL, SQLite, and HSQLDB.

For these reasons, the plugin is best treated as a convenient browser-based way to connect to and query accessible databases—not as a replacement for a fully featured database IDE.

When is it useful?​

The plugin is particularly handy when a team needs occasional or straightforward access to test databases, or when several database connections are available from the PacOS environment. Instead of asking each tester or developer to install and configure database software, you can configure the connections centrally in PacOS and make the browser-based interface available to the team.

As always, expose PacOS only to the people who should have access to it, and configure database permissions and network access deliberately.

Routine tasks such as retrieving a log, replacing a configuration file or unpacking test data can mean finding the right container and running docker exec, docker cp or shell commands.

PacOS provides a browser-based alternative. Mount the directories you want to work with into the PacOS container, then access them from the Explorer plugin.

1. Give PacOS access to the directories you need​

PacOS can work with directories mounted into its container. The example below runs two instances of the same backend image, each with its own logs and configuration volume. PacOS mounts those same volumes, so both instances' files are available from one place.

services:
  pacos:
    image: YOUR_PACOS_IMAGE
    container_name: pacos
    ports:
      - "8086:8086" # Example only; use the port configured for your PacOS deployment
    volumes:
      - backend1_logs:/shared/backend1/logs
      - backend1_config:/shared/backend1/config
      - backend2_logs:/shared/backend2/logs
      - backend2_config:/shared/backend2/config
    restart: unless-stopped

  backend1:
    image: YOUR_BACKEND_IMAGE
    volumes:
      - backend1_logs:/app/logs
      - backend1_config:/app/config

  backend2:
    image: YOUR_BACKEND_IMAGE
    volumes:
      - backend2_logs:/app/logs
      - backend2_config:/app/config

volumes:
  backend1_logs:
  backend1_config:
  backend2_logs:
  backend2_config:

Replace YOUR_PACOS_IMAGE, YOUR_BACKEND_IMAGE, the example paths and the port with values from your environment. Both backend services use the same image but have separate volumes, so each instance's files remain distinct. PacOS mounts each volume at its own path.

You can use the same pattern for more instances, other services, existing named volumes or bind mounts. If you scale a single Compose service dynamically, plan how each replica's files are stored and exposed; the explicit backend1 and backend2 services above illustrate the idea without assuming that every replica gets an automatically separate volume.

Security note: mount only the directories PacOS needs. Writable mounts allow file changes and deletion. Secure access to PacOS and review the permissions on exposed directories.

2. Install the Explorer plugin​

The file-management interface is provided by the Explorer plugin. Install it during PacOS setup, or later from the PacOS App Store.

3. Browse mounted files​

After the plugin is installed, Explorer lets you browse directories that are accessible inside the PacOS container. You do not have to configure named locations for this to work.

The Locations section in Explorer is an optional convenience: it lets you create named shortcuts to paths you use often, making them easier to find. It does not grant filesystem access or mount directories by itself. The actual access is determined by the Docker volume or bind-mount configuration.

To add shortcuts, open Application → Settings → Explorer, enter a friendly name and a path that exists inside the PacOS container, then save the configuration. Non-existent paths will not be displayed.

For example, shortcuts could be named backend1_logs, backend1_config, backend2_logs and backend2_config, pointing to the corresponding mounted paths.

4. Manage files from one place​

Select a location in Explorer or browse the available filesystem paths directly.

Explorer supports everyday file operations such as:

• Browse directories and open files.
• Create, rename, copy, move and remove files or directories.
• Upload and download files.
• Pack files into supported archive formats and extract archives.

This is useful for tasks such as updating configuration, exchanging test data or retrieving generated artifacts without repeatedly switching between containers and running shell commands.

5. Open log files with G-Logger​

If you often inspect application logs, you can use Explorer together with G-Logger, a PacOS plugin for viewing log files. Explorer helps you find and manage files; G-Logger adds log-focused features such as searching, following changes and keeping multiple files open in tabs.

G-Logger can also be used on its own: it includes a file picker, so Explorer is not required just to open a log. Read the G-Logger guide for details about working with large log files.

One browser-based workspace for your environment​

Mount the directories you want to access into PacOS, then use Explorer to browse and manage them from the browser. Configure named locations only if you want shortcuts to frequently used paths. If you also need to search or follow log files, see the G-Logger guide.

PacOS does not need access to every container's entire filesystem—only to the directories you choose to expose through mounts.

Try PacOS · Open the demo