Getting Started With Live SaaS Kit in a Phoenix Application

In this tutorial, I will go through how to add Live SaaS Kit to a fresh Phoenix application. The starting point is an empty mix phx.new my_app. The goal is a project that can install the first real foundation feature with a single Mix task instead of writing the same plumbing by hand.

Live SaaS Kit installs through a CLI package called saas_kit. The package talks to livesaaskit.com using a boilerplate token, receives a list of file operations, and applies them locally. Nothing is generated remotely. It is luckily very easy to get started with.

Step 1 - Create the Phoenix application

First step is to generate a fresh Phoenix project I can install into.

mix phx.new my_app
cd my_app

I use the default Postgres setup. The kit currently targets Phoenix ~> 1.8 and Elixir ~> 1.16, so I make sure my installed versions match before continuing.

Step 2 - Add the saas_kit package

Next step is to add the installer package to mix.exs. I add it as a :dev dependency because it is only used at install time, not at runtime.

# mix.exs
defp deps do
  [
    # other deps
    {:saas_kit, "~> 2.6", only: :dev, runtime: false}
  ]
end

Then I fetch it.

mix deps.get

Note that runtime: false keeps saas_kit out of the production release. It is a Mix task package, not a runtime library.

Step 3 - Configure the boilerplate token

Now that the package is available, I need to tell it which boilerplate to talk to. I get the token from my boilerplate page at livesaaskit.com and add it to config/config.exs.

# config/config.exs
config :saas_kit,
  boilerplate_token: "your_token_here"

The token uniquely identifies the boilerplate on the server side. Every install request carries it, so the API knows which feature catalog and options to return.

Step 4 - Run the initial setup

With the token in place, I can run setup. This creates a .saaskit.yml in the project root and optionally writes guidance files for coding assistants like Claude Code, Codex, Cursor, or GitHub Copilot.

mix saaskit.setup

For a non-interactive run, for example inside a script, I pass --agent-skills or --no-agent-skills so the task does not prompt.

The created .saaskit.yml starts out small.

# .saaskit.yml
initial_install: false

The initial_install: false line tracks whether the first feature install has happened. Later Mix tasks read this file to suggest the right next step.

Step 5 - Verify with status

The last thing I want to do is confirm everything is wired up. mix saaskit.status reports the config, the app name returned by the API, and the suggested next command.

mix saaskit.status

A configured project prints something like:

✓ Configured

  App:      My App (my-app)
  Next:     mix saaskit.feature.install authentication

If the token is missing or wrong, the same task prints ! Not configured along with the exact config snippet to add. So this is also the command I re-run any time something feels off.

Final Result

I can now run mix saaskit.feature.list to see the catalog and mix saaskit.feature.install <slug> to install the first feature. A natural next step is to add the foundation: authentication, layouts, and teams. I will leave that to the next tutorial in this series.