Mako Specific Features

The Mako Server is developed by using the Barracuda Embedded Application Server library and the Lua API provided by the Mako Server is identical to the Lua API provided by the Barracuda Application Server. The following documentation is for the features specific to the Mako Server. The source for most of these features can be found in and

Application environment and the .preload script

The Mako Server creates an application table/environment per loaded application. This table is known as the "app" table and is explained in the Barracuda Embedded Web Server manual under the section Command (Request/Response) Environment.

The Mako Server looks for the file .preload when starting an application. This file is loaded and executed as a Lua script, if found. The Lua environment (_ENV) for this file is the "app" table.

Preload script

When to use a .preload script:

The Lua code is typically not embedded in LSP pages if you write functions that are designed to be re-used by several LSP pages or if you write Lua code that is using the more advanced features of the Barracuda Application Server API's.

Functions and data in the .preload script are added to the application table. You can access this table from an LSP page as "app". For example, a function such as myfunc() can be accessed from an LSP page as app.myfunc().

The Mako Server has the concept of an application environment. The environment for an application is a location where you can keep commonly used Lua code, i.e. library functions. This environment is available to LSP pages in the application, but not to LSP pages in other applications. The application environment is referred to as the application table in our documentation. The Mako Server provides a number of environments that can be used by LSP programmers. See the tutorial Lua Environments and the .preload Script for more information.

Global Variables:

The server makes the following global variables accessible to the loaded applications:

  • mako.argv is a Lua table that contains all command line arguments. Arguments not understood by the Mako Server are ignored and you can therefore add your own arguments that can be used by your loaded application(s).
  • mako.env is the environment provided as a Lua table, if provided by the process that started the Mako Server.
  • mako.execpath is the directory where the Mako Server executable is installed.
  • mako.cwd is the server's current working directory.
  • mako.cfgfname is the configuration file's path and name.
  • mako.cfgdir is the directory where the configuration file was found.
  • mako.port is the HTTP port number the server is listening on.
  • mako.sslport is the HTTPS port number the server is listening on.
  • mako.dos2unix is a function that on the Windows version translates a Windows path to a path that can be used by the I/O interface.

The "require" Function

The "require" function searches for Lua files in the same locations where the standalone Lua interpreter searches. We provide one extension to "require" in the Mako Server that enables you to load Lua scripts from Mako applications. The loader is by default disabled for the Mako application. To enable the loading of Lua script modules from your application, add the following line to the beginning of the Mako Server's .preload script.

mako.createloader(io) -- io is the Mako application's I/O interface

The loader enables "require" to search for files in ".lua", which must be a sub-directory in your Mako Server application. The loader works for deployed and non deployed Mako Server applications. Recall that a deployed application is a ZIP file and a non deployed application is a regular directory on your file system.

Note: the function mako.createloader() was added to Mako Server 1.4, which is currently not released. You can download an updated, which includes this functionality.

The Mako Server example application shows how to use function "require" with Lua modules in a Mako application. Download the ZIP file and start the Mako Server as follows:


Using AJAX, SMTP, SOAP, JSON, XML-RPC, and/or the Web File Manager

The Mako Server consists of one executable file and one optional ZIP file named This file is required if you plan on using any of the following libraries: AJAX, SMTP, SOAP, JSON, XML-RPC, and the Web File Manager. These libraries use components developed in Lua and these components are packaged into The Mako Server automatically loads this ZIP file if found. This ZIP file should be in the directory where you install the Mako Server executable or in the directory where you place the configuration file. We recommend that you unpack and study this file. The file includes several additional resources such as the jQuery library.

Note: the mako ZIP file is also installed into the Mako Server's virtual file system using base URI '/rtl/'. You can access the resources in this ZIP file with a browser using the URL http://your-server-address/rtl/resource-name

Mako Server on Linux

The last print statement in the image to the right shows how the Mako Server loads the resouce ZIP file The image to the right shows how the ZIP file was automatically found by the Mako Server since the ZIP file is in the same directory as the Mako Server executable.

Mako Server I/O interfaces

The Barracuda Application Server provides an IO interface in addition to the standard Lua input/output operations. These IO interfaces must be created by the "C" startup code, and the Mako Server startup code creates the following IO interfaces:

  • disk: The root directory. This will be '/' on a Linux system and a virtualized root on Windows.
  • home: The home directory is the directory where the Mako Server was started. The home directory should only be used when running the Mako Server as a foreground process.
  • net: An uninitialized NetIo. This IO object can only be used for cloning new IO objects by using function ba.mkio.
  • vm: The Lua virtual machine's default IO will be if this ZIP file was loaded at startup. It will otherwise be the ZIP file embedded inside the Mako Server executable.

The following example shows how to list all IOs on the Mako Server:

for name,io in pairs( do
   print(name, ":", io:realpath"", " : ", io:resourcetype())

The above example produces the following output when run on Linux:

disk    :       /        :      disk    POSIX
home    :       ./       :      disk    POSIX
net     :       nil      :      net
vm      :       nil      :      zip     zip

Mako Server Specific Functions and Variables

function mako.sharkclient()
Returns a SharkSSL object initialized with the certificates in the the file .certificate/CA_list.p7b. The certificate file can be found inside A SharkSSL client object is required when creating a secure client connection such as an HTTPS connection or using the SMTP library in secure mode.

function mako.getapps()
Returns a table with all apps loaded by the Mako Server. The following example restarts all applications:

for ix,path in ipairs(mako.getapps()) do print("Reloading:",path) mako.reloadapp(ix) end

function mako.stopapp(x)
Stops a registered application. Parameter x is either the application's environment or an index position returned by function mako.getapps().

function mako.startapp(x)
Starts a registered application. Parameter x is either the application's environment or an index position returned by function mako.getapps().

function mako.reloadapp(x)
Reloads the .preload script for an app. Parameter x is either the application's environment or an index position returned by function mako.getapps(). The following code snippet can be used by an LSP page to reload the .preload script for the app:

mako.reloadapp(app) -- reload 'self'

function mako.createapp(name, priority, path [,conf])
Dynamically create and load a new application.


  • name - string: The base URI for the loaded application; for example, an application with name 'myapp' will have the base URI '/myapp/'. The application's root directory is then accessed as http://server-name/myapp/. The application is installed as a root application if you do not provide a name -- i.e. the base URI will be '/' and the application's root is then accessed as http://server-name/
  • priority - number: The applications priority can be set if you have multiple applications with the same name or you have multiple root applications. The default priority is zero.
  • path - string: The application's directory, ZIP file, or URL. Non deployed applications are typically directories and deployed applications are typically loaded as ZIP files.
  • conf - table: The optional 'conf' parameter is only used when the path is a URL to a Web File Server. The 'conf' parameter is passed into function io:netconf. Secure connections require the 'shark' attribute in the conf parameter. The shark attribute is automatically set to the return value of mako.sharkclient() if conf is not set or if the shark attribute is missing.

function mako.loadcerts()
Reload the SSL certificate(s) listed in mako.conf. The function enables an application to install new SSL certificates and then load the new certificates without having to restart the server. The Mako function loadcerts() is internally using the BAS function ba.create.servcon in the mode that enables it to recycle an existing server listening connection.

function mako.logfile(name)
Change logfile name/location. This function enables you to dynamically change the name and/or location of the log file in a running system. The argument "name" is the full logfile name including the path, which can be a relative path or an absolute path. The function returns true on success.

Boolean value, set to true if the server runs in the background