Plugins

Introduction

Vito supports plugins to extend its functionality and integrate with various services.

Plugins can be used to add new features or change the behavior of existing ones.

What can Plugins Do?

Plugins can change or extend the following features:

• Server Providers: Add support for new server providers or modify existing ones.
• Storage Providers: Integrate with new storage providers or modify existing storage functionalities.
• Source Controls: Integrate with new source control systems or modify existing source control functionalities.
• DNS Providers: Integrate with new DNS providers or modify existing ones.
• Notification Channels: Integrate with new notification channels or modify existing ones.
• Services: Add new services or modify existing ones.
• Site Types: Add new site types or modify existing ones.
• Site Features: Add new site features or modify existing ones.
• Server Features: Add new server features or modify existing ones.
• Workflow Actions: Add new actions that can be used in workflows.
• Console Commands & Views: Register console commands and views used by your plugin.

Installing and Managing Plugins

Vito offers official and community plugins. Official plugins are developed and maintained by the Vito team, while community plugins are developed by the community.

Install

You can install and manage plugins through the Vito web interface. Just navigate to the Admin > Plugins section, and find Official and Community tabs to browse and install plugins.

Enable

After installing a plugin, In order to use the plugin, you need to enable it. You can find the installed plugins in the Installed tab in the Admin > Plugins section. Click on the three dots on the right side of the plugin and then click on Enable.

Disable

Disabling a plugin will stop it from being booted by Vito. However the plugin's code will still live in your Vito instance and you can enable it again.

Uninstall

If you don't need a plugin anymore, you can uninstall it. Uninstalling a plugin will remove its code from your Vito instance.

Plugin Development

Creating a Plugin

Plugins are basically code extensions that are installed via Vito's plugin management system.

Plugins will live inside app/Vito/Plugins directory and will be a part of the Vito application.

You can use Vito's plugin template to create a new plugin.

Local Setup

In order to develop plugins locally, you can put them directly into the app/Vito/Plugins/YourGithubUsername/YourRepoName and Vito will discover your plugin.

Plugin.php

Every plugin must have a Plugin.php file in its root directory which extends the App\Plugins\AbstractPlugin class.

The Plugin.php must implement the boot method where you can register your plugin's features.

Example:

<?php

namespace App\Vito\Plugins\RichardAnderson\LaravelOctanePlugin;

use App\Plugins\AbstractPlugin;
use App\Plugins\RegisterSiteFeature;
use App\Plugins\RegisterSiteFeatureAction;
use App\Vito\Plugins\RichardAnderson\LaravelOctanePlugin\Actions\Disable;
use App\Vito\Plugins\RichardAnderson\LaravelOctanePlugin\Actions\Enable;

class Plugin extends AbstractPlugin
{
    protected string $name = 'Laravel Octane Plugin';

    protected string $description = 'Laravel Octane plugin for VitoDeploy';

    public function boot(): void
    {
        RegisterSiteFeature::make('laravel', 'laravel-octane')
            ->label('Laravel Octane')
            ->description('Enable Laravel Octane for this site')
            ->register();
        RegisterSiteFeatureAction::make('laravel', 'laravel-octane', 'enable')
            ->label('Enable')
            ->handler(Enable::class)
            ->register();
        RegisterSiteFeatureAction::make('laravel', 'laravel-octane', 'disable')
            ->label('Disable')
            ->handler(Disable::class)
            ->register();
    }
}

Discover Plugins

After you create your plugin, you will need to navigate to the Admin > Plugins section in the Vito web interface and then Discover tab.

Your new plugin should be listed there and you can install it from there.

Error Handling

Vito records every error that happens in the plugins when they're being booted and in case of an error, it will disable the plugin and show the error message in the Admin > Plugins section.

You can also see the stack trace of the error by viewing the error logs of a plugin to debug it.

Register site types

By registering a site type, you can add a new type of site that can be created in Vito.

Use App\Plugins\RegisterSiteType to register a new site type using the boot method of your Plugin.php file.

\App\Plugins\RegisterSiteType::make('symfony')
    ->label('Symfony')
    ->handler(SymfonyHandler::class)
    ->form(\App\DTOs\DynamicForm::make([
        \App\DTOs\DynamicField::make('php_version')
            ->component()
            ->label('PHP Version'),
        \App\DTOs\DynamicField::make('web_directory')
            ->text()
            ->label('Web Directory')
            ->placeholder('For / leave empty')
            ->description('The relative path of your website from /home/vito/your-domain/'),
    ]))
    ->register();

The handler method should point to a class that extends App\SiteTypes\AbstractSiteType or implements App\SiteTypes\SiteType.

Site type contract (v4.x)

In v4.x the vhost rendering model changed: instead of returning markup, a site type points at a template and supplies data to it. The SiteType interface now requires:

public function vhostData(): array;                 // data passed to the vhost template
public function supportedWebservers(): ?array;      // null = all webservers
public function vhostTemplate(string $webserver): ?string;
public function deploymentEnvironment(): array;     // extra env vars for deploys/commands
public function afterDeploy(Deployment $deployment): void;
public function defaultDeploymentScript(): string;

If you extend AbstractSiteType, defaults are provided for all of these, so existing plugins will not fatal. The old vhost(string $webserver) method has been removed, so move your markup into a Mustache template and return its name from vhostTemplate(), supplying variables via vhostData(). By default defaultDeploymentScript() reads resources/deployment-scripts/{id}.sh.

The protected progress() helper signature also changed to progress(int $percentage, ?string $step).

Optional tooling hooks let a site type declare the Site Tooling it needs: static supportsTooling(): bool, static requiredTooling(): array, and static createTimeTools(): array.

Application runtime presets (Beta)

Applications use runtime presets independently of Site types. Presets only suggest editable defaults; core deployment and component code must not branch on framework names. Extend App\RuntimePresets\AbstractRuntimePreset, implement static id() / label() and explicitly choose a WebMode: FPM for PHP-FPM, PROXY for a managed application process, or STATIC for files only. There is no default mode.

For example, a Python preset can reuse the existing Mise tooling provider:

use App\Enums\WebMode;
use App\RuntimePresets\AbstractRuntimePreset;
use App\Tooling\PythonTooling;

class PythonPreset extends AbstractRuntimePreset
{
    public static function id(): string
    {
        return 'python';
    }

    public static function label(): string
    {
        return 'Python';
    }

    public function versions(): array
    {
        return PythonTooling::supportedVersions();
    }

    public function tooling(): ?string
    {
        return PythonTooling::id();
    }

    public function webMode(): WebMode
    {
        return WebMode::PROXY;
    }

    public function startCommand(): ?string
    {
        return 'python -m uvicorn main:app --host 127.0.0.1 --port "$PORT"';
    }
}

Register it in your plugin's boot():

\App\Plugins\RegisterRuntimePreset::make(PythonPreset::id())
    ->handler(PythonPreset::class)
    ->register();

The builder takes optional label() and form(DynamicForm) overrides; otherwise it uses the preset's label and form. The registry is component.runtimes. Application::preset() resolves a stateless handler. PHP and Laravel declare requiredServices($version) as ['php' => $version] and tooling() as composer; Mise runtimes return their ToolingRegistry tool id rather than requiring a server-wide Node service. toolingVersion($version) defaults to the selected runtime version; PHP and Laravel return 2 to install Composer 2 independently of the PHP version. executables($version) optionally maps command names to absolute executable paths. Runtime synchronization links these into the component's bin directory, which takes priority in deployment, worker and cron command paths. PHP maps php to /usr/bin/php<version> without changing the server default or another component's CLI. Other optional suggestions are webRoot(), startCommand(), schedulerCommand(), sharedPaths() and form(). Defaults are empty/null.

defaultScripts() returns build, pre-release, and post-release strings, read from resources/deployment-scripts/presets/{id}/{stage}.sh (missing files yield empty strings). Plugins can override this method to load their own files. These are suggested script contents, not executed during registration. Existing Site deployment scripts are unchanged.

Additional extension points:

• warnings(Environment $environment): array returns advisory strings shown on the overview and Variables page. Keep framework-specific recommendations here, not in core Actions or UI.
• vhostData(Component $component): array derives webserver data from the selected web mode. The default uses the component's current release/web directory, its user/version FPM socket or its loopback proxy port. SyncComponentVhost remains the only vhost writer; presets must not write configuration themselves.
• detect(RepositoryFiles $files): ?array recognizes the runtime in a repository and returns compatible versions, newest first, or null. Presets are asked in reverse registration order, so a plugin preset wins over the built-in ones.
• additionalTooling(): array installs extra tooling on every component, keyed by tooling id with the version.
• defaultVariables(Environment $environment, array $input): array seeds variables into new environments. creationForm() and creationRules() add optional fields for them.
• suggestsDatabase(): bool turns the database option on by default when creating an application.
• Source control plugins can implement App\SourceControlProviders\SupportsRepositoryInspection to enable detection. Without it, or when getFileContents() keeps the default empty result, Vito asks the user to pick a runtime.
• attachmentAliases(EnvironmentAttachment $attachment, array $generic): array adds a string map of resource-variable aliases. The default is empty; Laravel supplies its own DB_*/Redis conventions. These aliases have lower priority than explicit environment variables and are conservatively masked in UI responses. Never expose credentials through warnings, catalogue descriptors or dynamic-form defaults.

Application tooling opts into App\Tooling\TargetToolingInterface; its installForTarget(), uninstallForTarget(), installedVersionForTarget() and pathContributionsForTarget() methods receive ToolingTargetDTO::forComponent(). The existing ToolingInterface methods continue to receive a Site, so existing Site tooling plugins do not need to change. Built-in Mise and Composer providers support both contracts. Mise runtime versions and executable links are selected per component directory. Composer installs under the component's .local/vito/bin, without changing the user's shell profiles or shared Site installation. sharedTooling() defaults to true, protecting shared runtime installations from Site tooling removal; PHP and Laravel return false because their Composer installation is component-local. See Applications for the deployment and environment-file contracts.

Component capabilities (Beta)

Extend App\ComponentCapabilities\AbstractComponentCapability and register with:

\App\Plugins\RegisterComponentCapability::make(YourCapability::id())
    ->handler(YourCapability::class)
    ->register();

The handler receives its App\Models\ComponentCapability as the protected $capability property. Implement static id() / label() and override these hooks as needed:

• description(): string and surfaces(): array describe the capability and its UI tabs.
• requiredServices(AbstractRuntimePreset $preset): array lists server service types.
• form(AbstractRuntimePreset $preset): DynamicForm describes fields stored in the model's config. The registration builder also accepts a static form(DynamicForm) override in component.capabilities.{id}.form; null means use the runtime-aware handler form.
• validate(Component $component, Server $server): void delegates validation to an Action. Call parent::validate() to check ownership (including the server's project), null/array configuration, and required installed services (ready, stopped, or disabled). Invalid input throws ValidationException (422). Validation may normalize the model's in-memory config, but does not save it, run SSH, or dispatch jobs.

ComponentCapability::handler() resolves the handler. Built-ins are web, worker, and scheduler:

• Web needs a webserver. FPM additionally needs the environment's exact PHP version installed; proxy mode needs a process manager and a non-empty start command. web_directory is release-relative, cannot contain .., and defaults to the preset's web root. Empty means the release root.
• Proxy port is an editable non-privileged port (1024–65535). Empty values select the first available port in component.port_range (10000–19999 by default), excluding ports held by components and Sites on that server. The managed process will receive this value as PORT.
• Worker needs a process manager and unlocks workers for arbitrary background commands.
• Scheduler unlocks cron_jobs, permits only one scheduler per environment, and requires command unless the preset supplies a suggestion. Explicitly empty commands are rejected.

Callers that create/update capabilities must serialize validation and persistence per server for ports and per environment for schedulers; validation alone does not reserve either.

Remote lifecycle hooks are separate from pure validation:

• install(Component $component): void prepares the capability's owned services/configuration. Processes remain stopped until the first release.
• uninstall(Component $component): void removes only capability-owned resources and must be retryable.
• afterRelease(Component $component, Deployment $deployment): void runs after activation; built-in web/worker handlers start or restart processes, while scheduler commands load the env file on each invocation.

Delegate business operations to Actions, use the SSH facade and Blade scripts, and preserve ownership on failures so cleanup can retry. Use ComponentShell::wrap() for commands so the current release, per-directory runtime and literal env loader are respected. Never place variable values in Supervisor, cron, vhost or pool configuration. Only the deployment pipeline calls WriteComponentEnv; validation and registry boot must not do remote work.

Both registration builders require instantiable handler classes. Registry IDs are literal map keys, so dotted plugin IDs are supported; access the registry map rather than building dot-separated config paths.

Public descriptors appear in bootstrap under application.runtimes and application.capabilities. Plugin lifecycle Actions already invalidate the bootstrap version when plugins are changed.

Register site features and actions

Every site can have multiple features and every feature can have multiple actions.

For example, Laravel website has a feature called Laravel Octane which has actions like Enable and Disable.

You can register a new site feature for an already registered site type by using App\Plugins\RegisterSiteFeature in the boot method of your Plugin.php file.

Vito allows you to register a feature to a site with actions or register actions to an already existing feature.

// register feature
\App\Plugins\RegisterSiteFeature::make('laravel', 'laravel-octane')
    ->label('Laravel Octane')
    ->description('Enable Laravel Octane for this site')
    ->register();
// register actions for the feature
\App\Plugins\RegisterSiteFeatureAction::make('laravel', 'laravel-octane', 'enable')
    ->label('Enable')
    ->form(\App\DTOs\DynamicForm::make([
        \App\DTOs\DynamicField::make('alert')
            ->alert()
            ->label('Alert')
            ->description('Make sure you have already set the `OCTANE_SERVER` in your `.env` file'),
        \App\DTOs\DynamicField::make('port')
            ->text()
            ->label('Octane Port')
            ->default(8000)
            ->description('The port on which Laravel Octane will run.'),
    ]))
    ->handler(Enable::class)
    ->register();
\App\Plugins\RegisterSiteFeatureAction::make('laravel', 'laravel-octane', 'disable')
    ->label('Disable')
    ->handler(Disable::class)
    ->register();

Every feature must implement the App\SiteFeatures\FeatureInterface interface.

Every action must extend the App\SiteFeatures\Action class or implement the App\SiteFeatures\ActionInterface interface.

Register server features and actions

Servers can also have features and feature actions.

You can register a new server feature using App\Plugins\RegisterServerFeature in the boot method of your Plugin.php file.

Vito allows you to register a feature to a server with actions or register actions to an already existing feature.

// register feature
\App\Plugins\RegisterServerFeature::make('opcache')
    ->label('OPCache')
    ->description('Enable OPCache for PHP')
    ->register();
// register actions for the feature
\App\Plugins\RegisterServerFeatureAction::make('opcache', 'enable')
    ->label('Enable')
    ->form(\App\DTOs\DynamicForm::make([
      ...
    ]))
    ->handler(Enable::class)
    ->register();
\App\Plugins\RegisterServerFeatureAction::make('opcache', 'disable')
    ->label('Disable')
    ->handler(Disable::class)
    ->register();

Every feature must implement the App\ServerFeatures\FeatureInterface interface.

Every action must extend the App\ServerFeatures\Action class or implement the App\ServerFeatures\ActionInterface interface.

Register services

Vito is a service-oriented server management system. By default, it comes with some built-in services like Nginx, MySQL, Redis, etc.

However, you can register your own services using App\Plugins\RegisterServiceType in the boot method of your Plugin.php file.

RegisterServiceType::make(Nginx::id())
    ->type(Nginx::type())
    ->label('Nginx')
    ->handler(Nginx::class)
    ->configPaths([
        [
            'name' => 'nginx.conf',
            'path' => '/etc/nginx/nginx.conf',
            'sudo' => true,
        ],
    ])
    ->register();
\App\Plugins\RegisterServiceType::make('php')
    ->type('php')
    ->label('PHP')
    ->handler(PHP::class)
    ->versions([
        '8.4',
        '8.3',
        '8.2',
        '8.1',
        '8.0',
        '7.4',
        '7.3',
        '7.2',
        '7.1',
        '7.0',
        '5.6',
    ])
    ->data([
        'extensions' => [
            'imagick',
            'exif',
            'gmagick',
            'gmp',
            'intl',
            'sqlite3',
            'opcache',
        ],
    ])
    ->register();

If some versions can't be installed on an operating system, list them with unavailableVersions(), keyed by the operating system. Vito then rejects those versions on servers running it:

->unavailableVersions([
    \App\Enums\OperatingSystem::UBUNTU26->value => ['11.4', '10.11'],
])

Service Types:

Vito already supports multiple service types, and you can create alternatives for them.

For example, You can create an alternative web server service like Apache. or another database service like SQL server.

Supported service types are:

• webserver: Will be used for sites
• database: Will be used for databases
• monitoring: Will be used to monitor the server
• memory_database: Will be used for in-memory databases like Redis or Memcached
• php: Will be used for PHP versions
• nodejs: Will be used for Node.js versions
• process_manager: Will be used for Workers like Supervisor
• firewall: Will be used for firewall services like UFW or CSF

Service Handlers:

Depending on your service type, You will need to implement a handler for your service which implements the interface of that service type.

For example, If you develop a web server service, you will need to implement the App\Services\Webserver\Webserver interface or extend the App\Services\Webserver\AbstractWebserver class.

Service Config Files

You can register your service's config files using the configPaths method. Vito will allow you to modify these files in the Services page.

Register server providers

Vito already covers the most popular server providers like DigitalOcean, AWS, Vultr, Hetzner etc.

You can register your own server provider using the boot method in your Plugin.php file.

\App\Plugins\RegisterServerProvider::make('hetzner')
    ->label('Hetzner')
    ->handler(Hetzner::class)
    ->form(
        \App\DTOs\DynamicForm::make([
            \App\DTOs\DynamicField::make('token')
                ->text()
                ->label('API Token'),
        ])
    )
    ->defaultUser('root') // The default ssh user of the server that the provider will create
    ->register();

The handler must implement the App\ServerProviders\ServerProvider interface or extend the App\ServerProviders\AbstractProvider class.

Providers are offered the Ubuntu releases only. If yours can create other systems, list them with ->operatingSystems(config('core.operating_systems')). When Debian images log in as a different user, pass it with ->defaultUser('ubuntu', debian: 'admin').

To let users change some credentials after connecting, register an edit form with ->editForm(DynamicForm::make([...])) and implement the opt-in App\ServerProviders\HasEditableCredentials interface in the handler. Vito merges the changes into the stored credentials and calls connect() again before saving. Never put secrets in the edit form. To add a step-by-step guide button inside a field, use ->withGuide($steps).

Register storage providers

Vito supports multiple storage providers like S3 compatible, FTP, etc.

You can register your own storage provider using App\Plugins\RegisterStorageProvider in the boot method of your Plugin.php file.

\App\Plugins\RegisterStorageProvider::make('local')
    ->label('Local')
    ->handler(Local::class)
    ->form(
        \App\DTOs\DynamicForm::make([
            \App\DTOs\DynamicField::make('path')
                ->text()
                ->label('Path'),
        ])
    )
    ->register();

The handler must implement the App\StorageProviders\StorageProvider interface or extend the App\StorageProviders\AbstractStorageProvider class.

Register source controls

Vito supports multiple source control providers like GitHub, GitLab, etc.

You can register your own source control provider using App\Plugins\RegisterSourceControl in the boot method of your Plugin.php file.

\App\Plugins\RegisterSourceControl::make('github')
    ->label('GitHub')
    ->handler(GitHub::class)
    ->form(
        \App\DTOs\DynamicForm::make([
            \App\DTOs\DynamicField::make('token')
                ->text()
                ->label('Personal Access Token'),
        ])
    )
    ->register();

The handler must implement the App\SourceControls\SourceControl interface or extend the App\SourceControls\AbstractSourceControl class.

In v4.x the SourceControlProvider interface gained four methods: getSshPort(), static editableFields(), editRules(array $input), and editData(array $input). Extending AbstractSourceControlProvider provides safe defaults (SSH port 22, no editable fields); implementing the interface directly means you must add all four.

The RegisterSourceControl builder also accepts ->connectable(bool) and ->usableForSites(bool), and v4.x ships a built-in GitHub App provider.

Applications support is optional. Implement App\SourceControlProviders\SupportsApplications to add repositoryRules(), deployReadOnlyKey($title, $repo, $key), findDeployKey($repo, $key), and getPushBranches($payload). Key registration must reconcile retries by public key, and push parsing must ignore tag and branch-deletion events. Existing Site providers keep the three-argument deployKey($title, $repo, $key) contract and continue working without these additions.

Register DNS providers

Vito ships with Cloudflare out of the box, and you can integrate any other DNS provider with a plugin.

You can register your own DNS provider using App\Plugins\RegisterDNSProvider in the boot method of your Plugin.php file.

\App\Plugins\RegisterDNSProvider::make('cloudflare')
    ->label('Cloudflare')
    ->handler(Cloudflare::class)
    ->form(
        \App\DTOs\DynamicForm::make([
            \App\DTOs\DynamicField::make('token')
                ->text()
                ->label('API Token'),
        ])
    )
    ->register();

The handler must implement the App\DNSProviders\DNSProvider interface or extend the App\DNSProviders\AbstractDNSProvider class.

Register notification channels

Vito supports multiple notification channels like Email, Slack, etc.

You can register your own notification channel using App\Plugins\RegisterNotificationChannel in the boot method of your Plugin.php file.

\App\Plugins\RegisterNotificationChannel::make('slack')
    ->label('Slack')
    ->handler(Slack::class)
    ->form(
        \App\DTOs\DynamicForm::make([
            \App\DTOs\DynamicField::make('webhook_url')
                ->text()
                ->label('Webhook URL'),
        ])
    )
    ->register();

The handler must implement the App\NotificationChannels\NotificationChannel interface or extend the App\NotificationChannels\AbstractNotificationChannel class.

Register Workflow Actions

Workflows can be extended by adding new actions. You can register your own workflow action using App\Plugins\RegisterWorkflowAction in the boot method of your Plugin.php file.

You can find handful examples of workflow actions in the Workflow Actions

Tooling providers

v4.x introduces Site Tooling, which installs developer runtimes and package managers (such as Node, Bun, Yarn, and pnpm) for a site's isolated user.

A tooling provider implements App\Tooling\ToolingInterface, or extends App\Tooling\AbstractTooling (or App\Tooling\AbstractMiseTooling for runtimes managed by Mise). Providers are registered through the tooling.providers config array:

config([
    'tooling.providers' => array_merge(
        config('tooling.providers', []),
        [YourTooling::class],
    ),
]);

Events

Vito fires events during Service installation and uninstallation this way you can tweak/extend the installation process, for example by modifying configuration files or setting up database tables/records.

You can listen to these events in the boot method of your Plugin.php file:

use App\Events\ServiceInstalled;
use App\Events\ServiceUninstalled;

class Plugin extends AbstractPlugin
{
    public function boot()
    {
        Event::listen('service.installed', function (Service $service) {
            // Do something when the service is installed
            Log::info("Service installed: {$service->id}");
        });
        Event::listen('service.uninstalled', function (Service $service) {
            // Do something when the service is uninstalled
            Log::info("Service uninstalled: {$service->id}");
        });
    }
}

Store Service Data

You can leverage the Service's type_data property to store any additional data you need, don't forget to honor other's properties when mutating it.

Dynamic Fields

Dynamic fields are a set of input fields designed to collect inputs from the action forms. They can be used in site creation, site feature actions, and every other part that Vito enables you to extend.

Here are the list of supported fields:

• Text field
• Password field (with an optional show/hide toggle)
• Textarea
• Checkbox
• Select field
• Alert (with types: info, warning, error, success)
• Link
• Component (render a custom frontend component)

v4.x also adds tooling-aware fields for use with Site Tooling, such as a tooling picker and selector.

For more details, check App\DTOs\DynamicField::class

Hooks

Vito exposes hooks for install, uninstall, enable and disable of plugins. This means, if you implement these methods in your Plugin.php, they will be called when the respective action is performed.

Example:

<?php

class Plugin extends AbstractPlugin
{
    protected string $name = 'Name';

    protected string $description = 'Description';

    public function boot(): void
    {
        //
    }

    public function enable(): void
    {
        //
    }

    public function disable(): void
    {
        //
    }

    public function install(): void
    {
        //
    }

    public function uninstall(): void
    {
        //
    }
}

Register Commands

If your plugin wants to register any console commands, you need to register them via the RegisterCommand helper, as per below;

RegisterCommand::make(FetchCommand::class)->register();

Register Views

If your plugin needs to register any views to use within it's implementations, you will need to register these views with a unique name via the RegisterViews helper;

RegisterViews::make('vitodeploy-reverb')
            ->path(__DIR__.'/views')
            ->register();

Publishing a Plugin

Vito has a community plugins section on the web interface that users can install plugins from. To list your plugin there, You need to publish your plugin as a public repository on GitHub and then add vitodeploy-plugin topic to it.

Versioning

Plugins are using Github tags and releases for versioning.

Updating Plugins

In order to check for available updates for your installed plugins, navigate to the Admin > Plugins section in the Vito web interface and then click on the Check for updates button. If there was an available update, you will be able to click on Update on every plugin's dropdown to update it.