Beyond Compute: Postgres, Cron Jobs & Emails

Today, we're adding managed Postgres, Cron Jobs, and Email support to Wasmer Edge.

We originally planned to announce each of these features separately. But all three are part of the same goal: making it possible to run a complete production application on Wasmer Edge.

Compute is only one part of an application.

Take a service that accepts user registrations. The HTTP handler is the easy part. The user needs to be stored in a database, a migration has to run before the new version receives traffic, expired sessions need to be deleted periodically, and a confirmation email has to be sent.

Each of those requirements becomes another service to configure and maintain.

Now you can handle all as part of your Wasmer Edge application.

Postgres

You can now attach a managed Postgres database to any Wasmer Edge application.

The database credentials are automatically injected at runtime using the standard DB_HOST, DB_PORT, DB_NAME, DB_USERNAME, and DB_PASSWORD environment variables.

But the part that I'm most excited about is how it plugs into our most recent launch: Anybuild.

When Anybuild inspects a project, it can detect whether the application needs Postgres. It looks for dependencies and configuration such as psycopg, pg, a Django Postgres engine, Laravel's pgsql driver, and other supported integrations.

If Postgres is detected, Anybuild can provision the database and configure the application automatically. The information Anybuild needs is already in the project structure, so there is no reason to ask the user to configure Postgres separately.

This is a managed regional Postgres instance attached to the application. It is different from the WASIX Postgres package running inside a sandbox.

Run work outside the HTTP request

Jobs are now fully supported on Wasmer Edge.

A job can run based on the following triggers:

• Cron jobs: On a schedule, using an interval such as 15m or 1h, or a cron expression such as /15 * * * *
• Deployment hooks: before or after a deployment (they run once per deployment)

Each job has one trigger and one action: execute or fetch.

Execute a command

An execute job creates a new sandboxed workload when the trigger fires. The job receives the application's environment and mounted volumes, runs the command, and then the sandbox is destroyed.

The command runs from the application package. But a job can also use a completely different Wasmer package, which is useful for a migration tool, a one-shot CLI, or a small Bash script that doesn't belong in the HTTP request path:

jobs:
  - name: migrate-database
    trigger: pre-deployment
    action:
      execute:
        command: migrate
        timeout: 5m
        retries: 2

  - name: write-heartbeat
    trigger: "*/15 * * * *"
    action:
      execute:
        package: wasmer/bash
        command: bash
        cli_args: ["-lc", "date -u && echo cron heartbeat"]

Pre-deployment jobs are especially useful for database migrations. Post-deployment jobs can warm caches or verify that the new version is responding correctly.

Fetch an endpoint

A fetch job calls an existing HTTP endpoint instead. Applications that already expose their scheduled work over HTTP (like WordPress) can make use of this:

jobs:
  - name: wp-cron
    trigger: "*/15 * * * *"
    action:
      fetch:
        path: /wp-cron.php
        timeout: 10m
        headers:
          - name: User-Agent
            value: Wasmer-CronJob
        expect:
          status_codes: [200, 204]

Fetch actions also support custom methods, headers, bodies, timeouts, and success conditions based on the response status or body.

All jobs support retries, timeouts, and max_schedule_drift. If a scheduled job starts later than the permitted drift, it is considered missed instead of running unexpectedly late.

Email

A lot of existing software already knows how to send email using sendmail.

PHP's mail(), WordPress plugins, cron scripts, and many Unix tools expect a sendmail binary to be available.

Rather than creating Wasmer-specific email API, we decided to follow the UNIX path: we published sendmail/sendmail: a sendmail-compatible binary that works inside Wasmer applications.

For this to work, you’ll need to enable the email configuration for your app, which will enable this plus a full SMTP server available for you to use.

enable_email: true

Then send email as usual:

echo "To: user@example.com
Subject: Confirm your account

Welcome." | sendmail -t

Messages are sent from a unique domain assigned to each Wasmer user. Pro accounts can currently send up to 10,000 emails/month.

We are also working on inbound email, so Wasmer applications will eventually be able to receive and process messages directly.

What doesn't work yet?

These features are new, and there are a few current limitations:

• Each application can have one attached database in one supported Edge region.
• Scheduled jobs have a minimum interval of five minutes.
• Outbound email currently uses a Wasmer-assigned domain to each user and is limited to 10,000 messages for Pro accounts.
• Inbound email is not available yet.

A complete application on the Edge

We want enable complete applications without having to assemble solutions from five different vendors.

Managed Postgres, Jobs, and Email are available today on Wasmer Edge.

Give them a try and let us know what you build!