This guide focuses on production-ready Caddy configurations that streamline deployments for self-managed Xojo applications, delivering:

• Automated TLS certificate management
• Native load balancing between instances
• Simplified configuration compared to traditional proxies
• Header optimizations specifically tuned for Xojo’s framework

You’ll learn configuration strategies that in some benchmarks, can have resource savings as high as 40% over conventional proxies while maintaining Xojo’s signature performance characteristics.

Core Configuration Strategies

Basic Reverse Proxy Setup

yourdomain.com {
    # Connect to Xojo application
    reverse_proxy localhost:8080 {
        # Preserve client information
        header_up X-Forwarded-For {http.request.remote.host}
        header_up Host {http.request.host}
    }
    
    # Automate HTTPS
    tls admin@yourdomain.com
}

Note: The header_up directives ensure Xojo correctly logs client IPs in web events

Load Balancing Across Instances

app.yourdomain.com {
    reverse_proxy localhost:8080 localhost:8081 localhost:8082 {
        load_balancer {
            policy round_robin
            health_interval 10s
            health_uri /health
        }
        # Timeouts for heavy processing
        lb_try_duration 30s
    }
}

Security Hardening Measures

yourdomain.com { 
	# Critical protection headers 
	header { 
		X-Content-Type-Options "nosniff" 
		X-Frame-Options "DENY" 
		Content-Security-Policy "default-src 'self'" 
	} 

	# Rate limiting for API endpoints 
	route /api/* { 
		rate_limit { 
			zone api 
			burst 100 
			period 10s 
		} 
	} 
}

Production-Ready Deployment Scripts

Linux Systemd Service
/etc/systemd/system/xojo-caddy.service:

[Unit]
Description=Xojo Caddy Reverse Proxy
After=network.target

[Service]
Type=simple
User=caddy
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

For a broader, step-by-step guide on preparing your server, please see our foundational tutorial: Tutorial: Deploying Web Apps on Linux. The systemd service above integrates perfectly into that workflow.

Windows Deployment Package
Xojo-Caddy.bat:

@echo off
REM Start Xojo application instances
start "Xojo Instance 1" /MIN XojoWebApp.exe --port=8080
start "Xojo Instance 2" /MIN XojoWebApp.exe --port=8081

REM Launch Caddy reverse proxy
start "Caddy Proxy" /MIN caddy.exe run --config C:\caddy\Caddyfile

Optimized Xojo-Caddy Template
Save as Caddyfile in your deployment root:

# Production-Grade Xojo Proxy Template
yourdomain.com, www.yourdomain.com {
    # Automated HTTPS
    tls contact@yourdomain.com
    
    # Primary app routing
    reverse_proxy localhost:8080 localhost:8081 {
        header_up X-Forwarded-Proto https
        header_up X-Real-IP {http.request.remote}
    }
    
    # Static content handling
    handle /static/* {
        root * /var/www/static
        file_server
    }
    
    # Security headers
    header {
        Strict-Transport-Security "max-age=31536000"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Conclusion

Caddy eliminates proxy complexity while delivering enterprise capabilities:

1. Simplified Operations: Single configuration file replaces complex proxy setups
2. Automatic Security: Continuous HTTPS protection without maintenance
3. Effortless Scaling: Built-in load balancing grows with your user base
4. Reduced Overhead: 40% fewer resources than traditional proxies in benchmarks

Implement the provided Xojo-Caddy template to achieve production-grade deployment in under 15 minutes. Monitor performance via Caddy’s built-in /metrics endpoint and scale horizontally as traffic increases.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

First, in order to deploy a web app you’ll need a way to access the remote server using the Terminal (macOS) or through the Command line, also a way to create and/or modify several files, and to copy files from your local computer to the remote server using (S)FTP.

Note: While we are using the “root” user for all the operations to keep the tutorial as short as possible, including files/folders/directories creation/edition and also for launching the web app, you’ll probably want to create a specific user with the proper privileges/group configuration for this. As we all know, you don’t usually want to run anything as the root user!

Though this tutorial is focused on the deployment aspects of a web app, we’ll first create a very simple web app in Xojo. Feel free to use a web app of your own. At the end of this tutorial, you’ll find deployment of more complex web apps can follow the same basic principles.

1. The Web App

This very simple app will display a message when the button is clicked.  Start the Xojo IDE and choose Web from the Project Selector window:

Click on the WebPage1 item displayed in the Navigator to access the webpage Layout Editor.

Next, drag a button from the Library panel and drop it anywhere on the Layout Editor.

With the button still selected, add the Pressed Event Handler and type this line of code in the Code Editor:

MessageBox "Hola Mundo"

The classic “Hello World” en español, this is everything the web app will do.

2. Setting the Deployment Options

Click on the Shared option found under the Build Settings section in the Navigator. Next, enter 9000 as the port under the Build Settings section in the Inspector Panel.

Note: Adding the port is not required at this time because the port can be assigned when running the app once it is deployed to the server.

3. Compile the Web App

Make sure to choose the Linux checkbox in Build Settings. Then, select X86 64 bit from the Build popup menu in the Inspector Panel.

Next, click on the Build button in Xojo’s IDE toolbar. Once the app is compiled, you’ll get a Folder/Directory with the following items inside:

This is the folder you will copy to the server. I’m using the Cyberduck app on macOS but you can choose any method you like.

4. Copying the App Folder to the Server

Make sure to copy the folder with the compiled app to the /var/XojoApps path on the server (you’ll need to create that folder/directory first). Once all the files have been copied, make sure to set 750 as the privileges value for the folder and files (choose the option to apply these recursively to all of them).

5. Installing Nginx

If the server doesn’t have Nginx already installed, install it now. Nginx is a light web server which provides more performance when compared with Apache (that is, it is able to serve more requests per second, among other improvements).

To install Nginx, access the remote server using SSH:

> SSH root@xxx.xxx.xxx.xxx

Once the new session is open, type the following commands to install Nginx:

$ sudo apt update
$ sudo apt install nginx

6. (Really) Basic Firewall Configuration

Let’s tackle the firewall. It will need to accept incoming connections from Nginx. Nginx registers itself as a ufw service during its installation. In order to simplify the deployment example, use the most restrictive option allowing only web traffic from port 80:

$ sudo ufw allow 'Nginx HTTP'

Type the following command to verify the changes:

$ sudo ufw status

The output should be similar to this (in my case access from SSH and 8080 ports are also enabled).

Note: This tutorial does not discuss web security which in the overwhelming majority of cases should be a paramount issue and not ignored. Securing a server is a very complicated process which is why we take care of the for you with Xojo Cloud.

7. Creating a New Nginx “block”

Once Nginx is installed, Ubuntu automatically starts this process, so the web server should be active already. Test this by typing:

$ systemctl status nginx

The output  should be similar to this:

Once the server is running, create a new server block. Think about this block like the virtual hosts on Apache. They will encapsulate the configuration details and will allow hosting of more than one domain on the same server.

Nginx loads these configuration files from the /etc/nginx/sites-available path. Create a new file using the nano editor:

$ sudo nano /etc/nginx/sites-available/XojoDemo

Next type the following block in the resulting new document:

server	{
listen 80;
listen [::]:80;
root /var/XojoApps/XojoDemo;
index index.html index.htm index.nginx-debian.html;

server_name xxx.xxx.xxx.xxx;

location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:9000;
}
}

Replace xxx.xxx.xxx.xxx with your server IP address or the server domain (DNS record, if you have one pointing to it). We are instructing Nginx to redirect the traffic from port 80 to 9000 where our web app will be listening.

Save the file and exit nano. Next, enable the file by creating a link from the file to the sites-enabled directory where Nginx reads the configuration files:

$ sudo ln -s /etc/nginx/sites-available/XojoDemo /etc/nginx/sites-enabled/

Finally, check for syntax errors in the Nginx configuration files:

$ sudo nginx -t

If everything is Ok, then reload Nginx so it reads the configuration files again and applies the changes:

$ sudo systemctl restart nginx

8. Executing the Xojo Web App

It’s time to start our Xojo web app and test the access from the web browser of your choice. Change the current path to the one where you copied the web app. In this example:

$ cd /var/XojoApps/XojoDemo

Next, start the app by issuing the following command:

$ ./XojoDemo --port=9000

Open a new window/tab in the web browser and enter the IP address/web domain pointing to the web server. There is the web app up and running:

Congrats! Now for the harsh truth. This way of executing web apps is not ideal. Because it started from the SSH session on the server, if we exit or interrupt the SSH connection, the web app will exit and won’t be accessible anymore for anyone. This problem also results in a 504 Gateway Time-Out page served by Nginx:

In order to fix this problem, create a Service.  A service will allow the app to run without any intervention, even if there is a server interruption, for example, if the server is restarted or the app crashes.

9. Creating a Service

Type the following in the current SSH session:

$ sudo nano /lib/systemd/XojoDemoApp.service

Next, type the following snippet of text in the new, opened document (make sure to save the changes once you exit nano).

[Service]
Type=simple
Restart=always
RestartSec=3
User=root
ExecStart=/var/XojoApps/XojoDemo/XojoDemo --port=9000
[Install]
WantedBy=multi-user.target

Now that you have exited nano, and with the new service created, activate it with the following commands:

$ sudo systemctl enable /lib/systemd/XojoDemoApp.service
$ sudo systemctl start XojoDemoApp.service

Get the service status by typing the following command:

$ sudo systemctl status XojoDemoApp.service

You should get an output similar to this:

Now, you can be confident that the Xojo web app will be running even if you close the current SSH connection with the remote server and that it will restart even if the remote server is restarted or the app crashes.

If all of this seems more complex than you care to manage, Xojo Cloud is the easy, powerful and secure way to deploy web apps. Xojo does not provide support for configuring your web server for use with Xojo web apps. To read more about deploying Xojo web apps, visit the Xojo Docs Web Deployment Overview and the Web Deployment Details pages.

1. Adding the database file

You probably created your SQLite database file using an external editor; so first add that file to your Xojo project.

You can do that in several ways, but usually it’s best to add a Build Step. This way, the file will be added automatically to the folder of your choice every time you compile your app. Bonus: Doing this allows you to decide to use different paths when debugging or deploying your app.

In order to add a new Build Step in a Desktop project select the target in the Build Settings then, from the contextual menu, choose the “Add to Build Settings > Build Step > Copy Files” option.

The previous action will give you access to the Inspector Panel for the just-added item where you will be able to type a name for the Build Step, choose if the copy file action will be executed both for debugging or deployment and, most importantly, choose the location where the file should be copied when the app compiles.

In fact, the Destination menu contains a number of typical paths (or most relevant folders). For example, a good Destination option would be “Resources Folder”. Of course, don’t forget to add the database file itself using the buttons on the Build Editor toolbar.

When you’re working with a Web project, you’ll find exactly the same behavior, even if you choose to deploy with Xojo Cloud.

On iOS, the only change is that you’ll have to choose the icon with an iPhone picture in it in order to access the Build Step contextual menu; in addition to the fact that every added resource needs to be signed with a certificate.

2. Copying the database file to a “Working” folder

You may think that the previous step is all you need to do, because if the database file is already copied in a well know path then you only need to provide that path as the DatabaseFile property on a new SQLiteDatabase or iOSSQLiteDatabase instance. But this is not the case.

They are many reasons you shouldn’t do that, specifically because the database would be open in read/write mode and if you write to that database file inside an application bundle, then you’ll be modifying a resource that would invalidate any certificate signature on your app.

The best thing to do is o detect every time you run the app if the database file has already been copied from the app bundle (or folder) into a target folder that doesn’t have an access problem when it is time to use the database. The Application Support folder is a good place for Desktop apps, while the Documents folder is fine for Xojo Cloud and iOS apps.

For example, if our database file is named “EddiesElectronics.sqlite” and our app name is “Xojotest”, then we can add the following code fragment into the Open Event Handler of a Desktop app:

Var source As FolderItem = SpecialFolder.Resource("EddiesElectronics.sqlite")
Var name As String = app.ExecutableFile.name.NthField(".",1)

// We check if there is a folder with the App name in special Application Data
// if not, we create it and copy the database file from Resources bundle/directory
If Not (SpecialFolder.ApplicationData.Child(name).Exists And SpecialFolder.ApplicationData.Child(name).IsFolder) Then SpecialFolder.ApplicationData.Child(name).CreateFolder
If Not SpecialFolder.ApplicationData.child(name).child(source).exists Then source.CopyTo(SpecialFolder.ApplicationData.Child(name))

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path
  pDatabase = New SQLiteDatabase
  pDatabase.DatabaseFile = SpecialFolder.ApplicationData.Child(name).Child("EddiesElectronics.sqlite")
  pDatabase.Connect

Catch e As DatabaseException
  MessageBox e.Message
End Try

For an iOS app, the code would be:

Var source As Xojo.IO.FolderItem = xojo.io.SpecialFolder.GetResource("EddiesElectronics.sqlite")

// We check if there is our database file already copied on the Documents Sandbox folder
// if not, we copy the database file from Resources bundle/directory
If Not xojo.io.SpecialFolder.Documents.Child("EddiesElectronics.sqlite").Exists Then
  source.CopyTo(xojo.io.SpecialFolder.documents)
End If

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path
  pDatabase = New iosSQLiteDatabase

  Var f As FolderItem = xojo.io.SpecialFolder.Documents
  pDatabase.DatabaseFile = f.Child("EddiesElectronics.sqlite")
  Call pDatabase.Connect

Catch e As RuntimeException
  MessageBox e.Reason
End Try

If you’re working on Xojo Cloud, the code will be even shorter. First, make sure that the Copy File Build Step has the following values in the Inspector Panel:

• Destination: Contents Folder
• Subdirectory: Documents

Then, the code will be:

Try
  pDatabase = new SQLiteDatabase
  pDatabase.DatabaseFile = SpecialFolder.Documents.Child("EddiesElectronics.sqlite")
  pDatabase.connect
Catch e as RuntimeException
  MessageBox e.Reason
End Try

What about a Web app that you host? That would mean you are in control about the folder/directory you want to use to store the app resources. Thus, it wouldn’t make much sense to automatize this process (but it is certainly doable following the same principles).

3. Simplifying the process

What we have seen already works, but that means that you need to change the file database name and probably that would change on every app you build. That also means that you’ll have to write the same code snippet again and again on every new app. Wouldn’t it be great to be able to extend the SQLiteDatabase and iOSSQLiteDatabase classes in order to simplify that?

Well, you can do that! Start by adding a new Module to the example project (for example one named “DatabaseExtensions”) with a couple of methods on it. The first method will be the one executed on our Desktop, Web and Console apps, because all of these targets use the SQLiteDatabase class.

So, add a new method using the following signature in the just-created module:

OpenDatabase( databaseName as String )

It extends the SQLiteDatabase class, adding a new method that takes as parameter the name of the file we want to copy on the “work” folder/directory.

The code you should type on this method is:

pDatabase = New SQLiteDatabase

#If TargetDesktop Or TargetConsole Or TargetWeb Then

  Var source As FolderItem = SpecialFolder.Resource( databaseName )
  Var name As String = app.ExecutableFile.name.NthField(".",1)
  // We check if there is a folder with the App name in special Application Data
  // if not, we create it and copy the database file from Resources bundle/directory
  If Not (SpecialFolder.ApplicationData.Child(name).Exists And SpecialFolder.ApplicationData.Child(name).IsFolder) Then
SpecialFolder.ApplicationData.Child(name).CreateFolder
If Not SpecialFolder.ApplicationData.Child(nam).Child(Source).exists Then source.CopyTo(SpecialFolder.ApplicationData.Child(name))

  Try
    // Create a SQLiteDatabase instance and try to open our database file from
    // the path
    pDatabase.DatabaseFile = SpecialFolder.ApplicationData.Child(name).Child(databaseName)
    pDatabase.Connect

  Catch e As DatabaseException
    MessageBox e.Message
  End Try

#ElseIf TargetXojoCloud
  Try
    pDatabase.DatabaseFile = SpecialFolder.Documents.Child( databaseName )
    pDatabase.connect
  Catch e As RuntimeException
    MessageBox e.Reason
  End Try
#EndIf

Of course, we need to add the “pDatabase” property to our module too: pDatabase As SQLiteDatabase

Now, you’ll only need to use:

OpenDatabase("EddiesElectronics.sqlite")

With the method selected in the Project Browser, click on the Attributes section of the Inspector Panel (the Cog Wheel icon), and uncheck the “iOS 64” checkbox. This way, that method will not be included when compiling for iOS apps.

Do the same thing with the “pDatabase” property, so it is only compiled on the supported targets.

The second method is the one we will be using for iOS apps. The method signature would be:

OpenDatabase(databseName as String)

And typing the following fragment of code in the associated Code Editor:

pIOSDatabase = New iOSSQLiteDatabase

Var source As Xojo.IO.FolderItem = xojo.io.SpecialFolder.GetResource( databaseName )

// We check if there is our database file already copied on the Documents Sandbox folder
// if not, we copy the database file from Resources bundle/directory
If Not xojo.io.SpecialFolder.Documents.Child( databaseName ).Exists Then
  source.CopyTo(xojo.io.SpecialFolder.documents)
End If

Try
  // Create a SQLiteDatabase instance and try to open our database file from
  // the path

  Var f As FolderItem = xojo.io.SpecialFolder.Documents
  pIOSDatabase.DatabaseFile = f.Child( databaseName )
  Call db.Connect

Catch e As RuntimeException
  MessageBox e.Reason
End Try

Lastly, and with the method item still selected in the Project Browser, go to the Attributes section of the Inspector Panel and make sure that the “iOS 64” checkbox is the only one selected under the “Include In” section. This way, we make sure that the method will be compiled only on iOS targets.

And do the same thing with the “piOSDatabase”, so it is only compiled for iOS targets.

To Summarize

As we see, the use of Modules in combination with OOP Class Extension is a good way to get more flexibility when developing your apps; using a common function (or method) name no matter if you are working on Desktop, Web or iOS. Additionally, that leads to a more convenient reutilization of your codeand, of course, less code to maintain through all our projects!

(You can find this article in Spanish here)

Like PHP, Xojo is object-oriented. Unlike PHP, Xojo has a coherent framework design that is easy to work with; plus the Xojo language is simple and focused.

Work Faster with an IDE

Save yourself time and trouble by using an integrated development environment (IDE). Why juggle text editors, FTP software, web servers and everything else you need to develop using PHP? With Xojo, you just need the IDE itself. Plus Xojo has a visual layout designer. You can design your web pages by dragging and dropping controls and positioning things how you want.

Learn One Thing

Rather than having to master the details of PHP, HTML, JavaScript, AJAX, CSS and other somewhat related technologies, with Xojo you only have to know Xojo. You write your code in the Xojo language. Don’t worry about HTML or JavaScript -although you can if you want, Xojo is flexible. Xojo creates the HTML, CSS, JavaScript and AJAX code on the fly at runtime.

Expandable

Do you have existing JavaScript controls that you want to use? Take advantage of the Xojo Web SDK, which provides an API for you to integrate JavaScript (and HTML) controls and frameworks into Xojo.

This is Yahoo’s Rich Text Editor in a Xojo web app:

Easy Deployment

Of course you can deploy your web apps to your own properly configured servers. But if you don’t have web server configuration experience or you just want a simple and secure deployment option, you can use Xojo Cloud. Hosting with Xojo Cloud is as easy as clicking the “Deploy” button in Xojo; your app is built and uploaded to your Xojo Cloud server for immediate availability. You don’t have to worry about permissions, security or configuration.

See a Xojo web app hosted on Xojo Cloud here: http://demos.xojo.com

Free to Develop

Xojo is free to use for learning and development. Download and try it today and see why people are choosing the simplicity of Xojo.

There is a simpler solution: Xojo. Using a single programming language and a single IDE, you can go from zero to a working web app in an amazingly short amount of time with Xojo.

User Interface Layout

We all know how slow and error-prone it is creating the user interface for your web app using code, which is what you have to do with most tools. But with Xojo’s Layout Editor, you just drag controls and position them where you want.

Xojo web apps work on desktop, tablet and mobile browsers. With the Layout Editor, you can design layouts for each type of browser for your app to switch between at ease.

Writing Code

The Xojo programming language and framework are event-based, fully object-oriented and incredibly easy to learn. With the code editor’s helpful auto-complete feature, you’ll be able to write code faster.

Xojo has the tools to help you code quickly, including a debugger that greatly simplifies tracking down bugs in your code.

Expandable

Xojo includes many built-in web controls, but it is also expandable. You can add your own JavaScript controls (and frameworks) to your Xojo web apps using the Xojo Web Software Development Kit (SDK).

For example, you can add the Yahoo Rich Text Editor to a Xojo web app as shown below.

Easy to Deploy

Xojo makes it easy to deploy your web apps. If you have experience configuring and maintaining web servers, you can deploy your Xojo web apps to your own server. If you’re not an expert server administrator, Xojo Cloud provides one-click web app deployment to our secure servers in one easy step!

Learn Quickly

Check out a live demo of our Eddie’s Electronic sample app and take a look at the full source code included in the Xojo download.  Or check out this growing playlist of videos to help you get started building web apps with Xojo.

Learn more about Xojo Web or just go ahead and download Xojo for free. Read the QuickStart, Tutorial, User Guide, and start developing your own web apps. You can develop, run and debug your app all before purchasing a license.

Geoff recently wrote about how to deploy iOS apps inside a company, but I’d like to collect all the various ways to deploy your iOS here for quick, easy reference.

Ad-Hoc Deployment to Devices

With Ad-Hoc Deployment, you build your iOS apps using an iOS Development Profile and manually copy the built app to the device. To create this profile you need to be a member of the Apple Developer Program (currently $99/year from Apple). You can deploy apps built in this manner on up to 100 devices.

There are step-by-step instructions on how to do this, which you can read about in the Xojo User Guide here: iOS Device Deployment.

TestFlight

For beta testing purposes, you can also use Apple’s TestFlight server to allow up to 1000 users to install a beta version of your app. Use of TestFlight also requires that you are a member of the iOS Developer Program.

Check out the Xojo Docs for instructions on how to use TestFlight: Submitting to TestFlight

App Store

To get your app in the hands of end users, you will typically want to use the App Store. To do so, you will build your app using an iOS Distribution Profile. You will have to be a member of the iOS Developer Program.

Check out the Xojo Docs for step-by-step instructions on how to build and submit an app to the App Store: Submitting to the iOS App Store.

Volume Purchase Program

As mentioned by Geoff in a previous post, the Volume Purchase Program provides a way for you to distribute apps to businesses or educational institutions without having to publish your app to the App Store. Apple has more information on this program:

• Volume Purchase Program for Business
• Volume Purchase Program for Education IT

Enterprise Deployment

Businesses can use the iOS Developer Enterprise Program to get tools and resources for developing proprietary, in-house iOS apps that you can distribute to your employees. These apps are distributed outside of the App Store.

For more information, visit the iOS Developer Enterprise Program.

Other Options

Other than jailbreaking your device, we are not aware of other options for deploying apps to iOS devices at this time.

Depending on the project, I’ve used two installers on Windows: Inno Setup and Advanced Installer. Both will create an installer that can place your app in Program Files, optionally create desktop and Start menu shortcuts, display a license agreement and much more.

Inno Setup creates setup.exe installers and is pretty easy to use once you get your script set up. The “QuickStart Pack” includes a Script editor that can help with that. Or you can grab one of the example scripts from the Xojo docs to get you started. There are examples for 32-bit and 64-bit Windows apps. Just replace the app names in the example with your app name, generate a new AppID (using Tool->Generate GUID in the menu) and you can build your installer.

Advanced Installer has a user interface that is quite easy to use, allowing you to create an installer just by selecting files and specifying settings. The free version can use the “Simple” template which will likely suffice for most Xojo developers, but they also have a more powerful paid versions ($400 to $3000). In addition to the nice UI, Advanced Installer can create MSI (Microsoft Installer) files, which are often preferred by IT departments. From what I understand, an MSI makes it easier to do remote and bulk deployments

There are plenty of other installers for Windows, including the popular and expensive InstallShield tools. I think that Xojo packages up your application so nicely that you are not likely to need all the capabilities that the more sophisticated tools provide.

For more information about deploying to Microsoft Windows, refer to these documentation topics:

• Desktop Deployment
• Inno Setup Script for 32-bit apps
• Inno Setup Script for 64-bit apps
• Video: Windows Installers

The Xojo Examples include sample Inno Setup scripts and some sample XojoScript you can use to kick it all off. These are located here:

• Examples/Platform-Specific/Windows/Making Installers