Add a service

Most applications need at least one service before they can run — a database to store records, a cache for sessions or queues, or both. This guide covers how to connect an application requirement to a service, whether strackt is setting one up fresh or you already have one running that you want to share.

Before you start: your application needs to be added already, and its requirements confirmed. If you haven't done that yet, start with Add and deploy an application.

Where to find your application's services

Open your application's settings and go to the Services section. This shows every database or cache your application declared as a requirement and whether each one is connected yet.

Requirements that haven't been connected show a Confirm action. Use that to set up the connection.

Connecting a requirement

When you click Confirm on a requirement, strackt checks whether a matching service is already available in your workspace.

If a matching service exists, the confirm step opens a choice:

• Connect to an existing service — use a service that's already running. strackt shows you the available services and picks a sensible default. This is the fastest path.
• Install new on this server — provision a fresh instance of this service directly on the application's server.

Pick the option that fits your setup and confirm. strackt records the connection immediately.

If no matching service exists, strackt proceeds straight to installing a new instance on the server — there's nothing to choose.

What strackt sets up

Once a requirement is confirmed, strackt handles the rest of the provisioning:

• On the next deploy, strackt creates the database and a dedicated user for your application. Your application only has access to its own database.
• The connection details — host, port, user, and password — are wired into your application's environment automatically. You don't copy credentials or edit config files by hand.

If you're connecting to a service on a different server, strackt configures the network path between them as well.

Which database you get

When your application needs a SQL database, strackt sets up MariaDB 11.4 LTS — every time. There's no engine to pick and no version to choose: the database picker offers MariaDB and gets you running with a setup that's tested across modern Laravel, WordPress, and Drupal.

If your application was written for MySQL, it runs on MariaDB without changes. The two are drop-in compatible for the things applications actually do, and standing on one well-tested version means fewer surprises when you deploy or upgrade. If strackt detects that your code expected a specific older version, it'll note what it found while still installing the current one.

After connecting

Your application is ready to deploy. Connection details are available as variables in your application's environment configuration if you need to reference them alongside other settings.

A pending change is queued for your application's server. It applies on the next deploy. If you're deploying for the first time, the connection is set up as part of that deploy.

If a service's credentials don't apply

Wiring an application to a service means creating its database and user on the service and handing the connection details to your application. Occasionally that last step — applying the credentials to the service — doesn't go through. When it does, strackt tells you the binding was saved but the credentials weren't applied yet, and offers a Retry pending changes action.

What it means: the connection is set up on strackt's side, but your application can't actually reach the service until the credentials land. Deploying an app that depends on it before then can fail to connect.

What to do:

1. Use Retry pending changes. This is the fix in almost every case — it reapplies the credentials to the service. Most failures here are transient (the service was briefly busy or the server was mid-update), so a retry clears them.
2. Check the service's server is online. Credentials are applied over a connection to the server the service runs on. If that server is offline or unhealthy, bring it back before retrying.
3. Hold off deploying dependent apps until it's applied. Wait for the retry to succeed before deploying an application that relies on this service, so it doesn't start up without a working connection.

If the retry keeps failing while the service and its server look healthy, reach out and we'll take a look with you.