Stackato Komodo IDE only

Stackato is a cloud application platform which is based on, and fully compatible with, Cloud Foundry. Stackato sets up virtual servers and deploys applications to them, automatically provisioning everything your application requires to run (language interpreter, web framework, modules, databases, and other services).

Komodo works in conjunction with the Stackato client to provide an interface to Stackato and Cloud Foundry-based services. More information on stackato can be found at:

Stackato Client Setup

To enable Stackato support in Komodo:

Once the client is installed and configured, the Tools|Stackato interface will be usable.

Connecting to Stackato

To connect to a Stackato API endpoint (e.g. 'https://api.stackato.local') enter the URL in the Target field and click Target.

Note: By default, Stackato servers will accept connections only over HTTPS.

Once the API endpoint is targeted, enter the username (an email address) and password, then click Login....

Viewing Target Info

Details of the targeted Stackato system can be seen using the buttons under the User field:

The Applications pane shows applications belonging to the current user that have been deployed to the target. It shows their current status, the number of instances running, what services are bound to each, and the application URL(s).

The Provisioned Services pane (collapsible) shows the services that have been provisioned for the current user, whether or not they are bound to applications.

The Stackato Output pane (collapsible) show the console output of the various Stackato commands as they run.

Creating Applications

New applications can be created by either right-clicking on an empty row in the Applications table and selecting "Add...", or pressing the "Add a new app" button in the toolbar above the Applications table (it's the one with the blue right-pointing arrow). This will bring up the New Stackato App Wizard, where you can set the properties on the application. Most of the properties should be straightforward:

Application Name
The name of the application. This should consist of only letters and digits, as the URL the form suggests is generated from the name. However the URL can be edited. Once it's edited, changing the application name no longer modifies the suggested URL.
The path to the root folder containing the application to push.
The URL of the application.

The remaining options, except debugging, should be straightforward. Note that on the next step of the wizard, you are given an opportunity to bind a service to the new application.

Debugging Applications

Stackato (versions 1.26 and higher) supports debugging of Rails, Sinatra, Django, and PHP applications remotely via Komodo. These applications can be debugged remotely in Komodo by checking the Debug App box on the first page of the New Application wizard, and filling in the host Komodo is running on, and the port it's watching. Normally Komodo can figure out what these values should be, but if you have a different scenario in mind, such as creating the Stackato app on one machine, but debugging it from another, you'll need to adjust these fields accordingly.

You can also switch an app into debug or non-debug mode by right-clicking its row in the main table, and pressing the Configure Debugger... menu item. This brings up a small dialog box which you can check the Debug Application and modify the host and/or port Komodo will listen on for debugging sessions. As with the application description wizard, the interface will get the port number from Komodo, but may not be able to determine the hostname. This is because the hostname field should contain the name or IP address the debugging machine is known to the Stackato VM.

Note that changing an application's debugging settings will cause the Stackato client to restage it, which might cause a delay on some systems.

Each type of app is debugged in a slightly different way:

For all supported languages, debugging sessions work better if the preference Debugger | Debugger/Editor Integration | Try to find files on the local system when remote debugging is checked. If you make changes to locally found files while debugging, you can save your changes and push the changes to the server.