Deployment

How to get your app running in production

Was this helpful?

Deployment

How to get your app running in production

Before deploy

Before deployment, we've found an issue in production with the new content security policy headers. Basically, you need to add wss://...and your domain to the :content_security_policy default_src array, like below.

config.exs

config :my_app, :content_security_policy, %{
  default_src: [
    ....
    "wss://yourdomain.com",
    "wss://yourdomain.com/live/websocket"
  ]
}

Removing CSP

If you don't care about content security policies, you can remove this config and then in router.exs change:

# Change this:
plug(:put_secure_browser_headers, %{
  "content-security-policy" =>
    ContentSecurityPolicy.serialize(
      struct(ContentSecurityPolicy.Policy, PetalPro.config(:content_security_policy))
    )
})

# To this:
plug :put_secure_browser_headers

Deployment with Fly.io

We have found Fly.io to be the best combination of cheap and easy. Petal Pro has been set up for users to quickly deploy on Fly.io's servers.

Once signed in, you can create a new project with:

fly launch

New: fly may prompt you with with a series of default settings and ask if you want to tweak them. Hit Y and it will open your browser with a UI where you can pick/choose settings.

Give your app a name (this can't be changed in future).
Under Database, choose "Fly Postgres", as we'll need that.
Pick a server size - we usually go with the cheapest configuration.
You can leave Redis as none.
Hit Confirm.

At this point, it may try to generate and deploy the app, but will fail, as we haven't told Fly to add our "petal" repo. See the section below on what to do next.

Building assets

In the generated Dockerfile you may need to add a small change to properly compile the assets.

Change:

RUN mix assets.deploy

to:

RUN mix assets.setup
RUN mix assets.deploy

Email sending

To be able to register/sign in, we'll need to ensure email is set up and we'll need a service to send our emails out. We've found that the simplest and cheapest solution is Amazon SES, and so Petal defaults to using this. Look in runtime.exs to see the setup:

config :petal_pro, PetalPro.Mailer,
    adapter: Swoosh.Adapters.AmazonSES,
    region: System.get_env("AWS_REGION"),
    access_key: System.get_env("AWS_ACCESS_KEY"),
    secret: System.get_env("AWS_SECRET")

We don't really use Amazon for much else, but its email service is cheap and the emails don't get sent to spam as easily as other services we've tried (cough cough Sendgrid).

fly secrets set AWS_ACCESS_KEY="xxx" AWS_SECRET="xxx" AWS_REGION="xxx"

Petal Framework

Telling Fly to add our "petal" repo

Since Petal Framework is not coming from hex.pm, we need Fly to know to add our Petal registry.

After running the fly launch command above, Fly has generated a dockerfile in the root of our project.

Open Dockerfile and search for this bit:

# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV
RUN mkdir config

Before those commands are run, we need to add the Petal repo. So, above this block of code you want to add the Petal repo:

# Add the Petal repo:
RUN --mount=type=secret,id=PETAL_LICENSE_KEY \
    mix hex.repo add petal https://petal.build/repo \
      --fetch-public-key "SHA256:6Ff7LeQCh4464psGV3w4a8WxReEwRl+xWmgtuHdHsjs" \
      --auth-key $(cat /run/secrets/PETAL_LICENSE_KEY)

# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV
RUN mkdir config

You may also need to add RUN mix assets.setup to the compile assets block of code.

# compile assets
RUN mix assets.setup
RUN mix assets.deploy

Finally, we can run fly deploy --build-secret PETAL_LICENSE_KEY=<your key>

If deployment fails here, you may need to add a payment method to your account as Fly only allows 1 machine per app.

After deploying you can run fly open to see it in your browser.

PreviousContributing NextTesting

Was this helpful?

Before deploy

config.exs

config :my_app, :content_security_policy, %{
  default_src: [
    ....
    "wss://yourdomain.com",
    "wss://yourdomain.com/live/websocket"
  ]
}

Removing CSP

If you don't care about content security policies, you can remove this config and then in router.exs change:

# Change this:
plug(:put_secure_browser_headers, %{
  "content-security-policy" =>
    ContentSecurityPolicy.serialize(
      struct(ContentSecurityPolicy.Policy, PetalPro.config(:content_security_policy))
    )
})

# To this:
plug :put_secure_browser_headers

Deployment with Fly.io

We have found Fly.io to be the best combination of cheap and easy. Petal Pro has been set up for users to quickly deploy on Fly.io's servers.

If you haven't already, download the . Then you will need to .

Once signed in, you can create a new project with:

fly launch

New: fly may prompt you with with a series of default settings and ask if you want to tweak them. Hit Y and it will open your browser with a UI where you can pick/choose settings.

Give your app a name (this can't be changed in future).
Under Database, choose "Fly Postgres", as we'll need that.
Pick a server size - we usually go with the cheapest configuration.
You can leave Redis as none.
Hit Confirm.

At this point, it may try to generate and deploy the app, but will fail, as we haven't told Fly to add our "petal" repo. See the section below on what to do next.

Building assets

In the generated Dockerfile you may need to add a small change to properly compile the assets.

Change:

RUN mix assets.deploy

to:

RUN mix assets.setup
RUN mix assets.deploy

Email sending

config :petal_pro, PetalPro.Mailer,
    adapter: Swoosh.Adapters.AmazonSES,
    region: System.get_env("AWS_REGION"),
    access_key: System.get_env("AWS_ACCESS_KEY"),
    secret: System.get_env("AWS_SECRET")

We don't really use Amazon for much else, but its email service is cheap and the emails don't get sent to spam as easily as other services we've tried (cough cough Sendgrid).

Setting up Amazon SES is beyond the scope of this tutorial. You can read their docs to set it up. The end result should be you are able to provide the following secrets that we'll provide to our production server:

fly secrets set AWS_ACCESS_KEY="xxx" AWS_SECRET="xxx" AWS_REGION="xxx"

If you don't want to use SES you can switch to a .

Petal Framework

Petal Framework is a hex package like any other. The only difference is the repo that you fetch it from. Normally your hex packages are fetched from . But Petal Framework is fetched from our private registry. We need to let Fly know about this.

Telling Fly to add our "petal" repo

Since Petal Framework is not coming from hex.pm, we need Fly to know to add our Petal registry.

After running the fly launch command above, Fly has generated a dockerfile in the root of our project.

Open Dockerfile and search for this bit:

# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV
RUN mkdir config

Before those commands are run, we need to add the Petal repo. So, above this block of code you want to add the Petal repo:

# Add the Petal repo:
RUN --mount=type=secret,id=PETAL_LICENSE_KEY \
    mix hex.repo add petal https://petal.build/repo \
      --fetch-public-key "SHA256:6Ff7LeQCh4464psGV3w4a8WxReEwRl+xWmgtuHdHsjs" \
      --auth-key $(cat /run/secrets/PETAL_LICENSE_KEY)

# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV
RUN mkdir config

You may also need to add RUN mix assets.setup to the compile assets block of code.

# compile assets
RUN mix assets.setup
RUN mix assets.deploy

Finally, we can run fly deploy --build-secret PETAL_LICENSE_KEY=<your key>

You can see your key in the on Petal (see Step 1 and copy the key written after "--auth-key").

If deployment fails here, you may need to add a payment method to your account as Fly only allows 1 machine per app.

After deploying you can run fly open to see it in your browser.