Deploy CData API Server to Azure App Service with SQL Server



Building a REST API on top of a database usually means writing backend code, and then maintaining it. And if you host that API on Azure App Service, there's a second catch: App Service instances don't keep local files for long. Restart the app and anything saved on the local disk is gone, including your settings.

CData API Server handles this by creating live REST and OData endpoints straight from your database tables, no backend code needed. And it can keep all of its configuration (settings, connections, API definitions, and user accounts) in a SQL Server database through one cdata.app.db connection, so nothing is lost on restart. In this article, we'll set up CData API Server on Azure App Service (Linux) with SQL Server as its configuration store.


Prerequisites

  1. An Azure subscription
  2. A SQL Server instance that Azure can reach (Azure SQL Database, or on-premises with public access)
  3. Java 17 on your local machine
  4. An FTPS client such as WinSCP or FileZilla

Step 1: Download and install the CData API Server

Download the Cross-Platform (.tar.gz) build, even if you're on Windows. This build has the raw apiserver.jar and webapp/ files that Azure App Service (Linux) can run directly.

  1. In CData API Server download the Cross-Platform (.tar.gz) build
  2. Extract the archive to a local folder (for example, C:\apiserver-work\)

After extracting, you'll see apiserver.jar, a webapp/ folder, a lib/ folder, and a few other files.


Step 2: Generate and edit the configuration file

Next, create the properties file that holds the settings.

  1. Open a command prompt in the folder where you extracted the files and run:
  2. java -jar apiserver.jar -GenerateProperties
    This creates apiserver.properties in the same folder. Everything you'll upload to Azure.
    Generating apiserver.properties with the -GenerateProperties flag
  3. Now point API Server at your SQL Server. Open apiserver.properties in any editor and change these three settings:
    • Config database connection tells API Server to keep its configuration in SQL Server instead of a local file:
    • cdata.app.db=jdbc:sqlserver://[server]:1433;database=[database_name];user=[username];password=[password];encrypt=true;
    • Data directory is a folder on the App Service where API Server keeps runtime data like logs and cache. This path works natively on App Service Linux:
    • cdata.app.directory=/home/site/apisrv_data
    • Port Azure App Service expects the app to listen on port 80, so change it from the default 8080:
    • cdata.http.port=80

Note: Before saving, replace [server], [database_name], [username], and [password] with your real SQL Server details. The login needs permission to create tables in that database, because API Server builds its tables there on first start.

apiserver.properties with the config database, data directory, and port set

Step 4: Create the Azure App Service

In the Azure Portal, create a new Web App with these settings on the Basics tab:

  1. Publish: Code
  2. Runtime stack: Java 17
  3. Java web server stack: Java SE (Embedded Web Server)
  4. Operating system: Linux
  5. Region: same region as your SQL Server, to keep latency low
  6. Pricing plan: Basic B1 or higher. The Free F1 tier only gives you 1 GB of disk
  7. Fill the basic settings for your webapp
  8. On the Deployment tab, turn on Basic Authentication (FTPS needs it)
  9. On the Networking tab, keep Public Access on. Leave the rest at defaults
  10. Enable public access in Networking
  11. Click Review + Create, to finish
  12. App is created and deployed successfully

Step 5: Upload the API Server files via FTPS

Time to move the file using app's resource page.

  1. Go to Deployment Center, and open the FTPS credentials tab. Copy the FTPS endpoint, username, and password
  2. FTPS credentials in the Deployment Center
  3. Connect your FTPS client with those credentials, using explicit TLS on port 21
  4. Connect your FPS client with credentials
  5. Go to /site/wwwroot/ on the remote side and delete the placeholder files Azure put there
  6. Upload webapp/, lib/, apiserver.jar, and apiserver.properties into /site/wwwroot/

Skip the jre/ folder as App Service brings its own Java 17.

Transferring the API Server files to /site/wwwroot/ over FTPS

Step 6: Configure the startup command

Now tell App Service how to start the JAR:

  1. In your App Service, open Configuration, then Stack settings
  2. In the Startup Command field, enter: java -jar /home/site/wwwroot/apiserver.jar
  3. Click Apply and Restart the App Service
Setting the startup command in Stack settings

Step 7: Access API Server and create your admin account

Open your browser and go to the default domain on the App Service Overview page (something like yourapp.azurewebsites.net). If everything worked, you'll see the API Server account creation page.

API Server account creation page confirming a successful deployment
  1. Create your admin account with a strong password
  2. Activate your 30-day trial license for testing

On first start, API Server creates its tables in the SQL Server database you set up. From now on, that's where your settings and user accounts live.

API Server configuration tables created in SQL Server

Troubleshooting

SQL Server driver error at startup:

  1. Download Microsoft's JDBC Driver for SQL Server and extract the ZIP
  2. Pick the JAR for Java 11 or later (mssql-jdbc-12.x.x.jre11.jar, not the .jre8 one)
  3. Upload it to /site/wwwroot/lib/ over FTPS and restart the App Service

Page not loading:

  1. Check the startup command in Stack settings
  2. Check that cdata.http.port=80 is set in apiserver.properties
  3. Open Log stream in the Azure Portal and look for Java errors

Configuration lost after restart:

  1. Check the cdata.app.db connection string
  2. Make sure Azure can reach your SQL Server. For Azure SQL, turn on "Allow Azure services and resources to access this server" in the firewall settings

Publish live REST APIs from Azure with CData

CData API Server is now running on Azure App Service, SQL Server holds its configuration, and any application can call your data through a public URL using standard REST and OData. Your settings survive every restart, and you're ready to scale when you need to. Download the free 30-day trial to try it with your own data. As always, our Support Team is happy to help with any questions.