Ory's blog has two blog posts about building a URL shortener using Ory Products and Supabase Database. Part 1 covers backend infrastructure and uses Ory Kratos and Oathkeeper. Part 2 covers a frontend part of the application. In this post, I will talk about moving from self-hosted to the Ory Network for the project, and we will discuss a path of migration to the Ory Network.
When I was building this demo project, I started from the 0.8 version of Ory
Kratos, and once I finished, the 0.9 version was released. I needed to make
minor changes to the configuration, such as changing
allowed_return_urls. That's usually not a big deal. Still, teams must upgrade
their dependencies time-to-time to prevent security issues and have more
The URL shortener project is a demo project and not deployed to any cloud environment, and using the Ory Network can be an overengineering and premature optimization. However, since I decided to deploy the service somewhere, I don't want to deal with the following things on production for Ory Kratos:
- Handle breaking changes for the configuration
- Upgrading version of Ory Kratos
- Running database migrations
- Updating the code not to use deprecated API endpoints
Hence, using the Ory Network seems a good idea because I can have decreased time-to-market and don't worry about upgrading versions of Ory Kratos, especially after the 0.8 release the Ory Network and Ory Kratos have 1:1 compatibility of APIs.
Let's start moving to the cloud, huh?
What services become obsolete after migration? Right now, the app uses the following containers:
kratosto run Ory Kratos.
kratos-migrateto run migrations against the database.
mailslurperto read sent emails for development purposes.
postgres-kratosto store identity data for Ory Kratos.
kratos-selfservice-ui-nodeto serve a user interface for login/signup/recovery flows.
oathkeeperthat serves as an identity and access proxy for the project..
After the migration to the cloud, we don't need them anymore.
As a prerequisite, I needed to create an Ory Network project, and I followed the documentation. In addition, I needed to install an Ory CLI tool. Once I had them installed, I came up with the following migration plan.
- Oathkeeper usage overcomplicates the app. I need to deploy it somewhere near the app, and I have only a couple of rules enabled. I can replace it with a small middleware.
- I don't need Ory Kratos anymore with self-service UI. Hence I need to test everything that would work with the Ory Network.
- I need to use the Ory proxy with the CLI installation for local development.
- Since I don't have any identities created, I can easily migrate without issues and write additional scripts to migrate the data.
Implementing an Ory Network middleware for the backend service. Let's replace
the content of
middleware/middleware.go with the following code
One can remove
oathkeeper directories and the
has the following content:
Ory Proxy is a reverse proxy deployed in front of your application. This allows the Ory endpoints to be mirrored on the same domain as the app you're running.
The Proxy rewrites cookies to match the domain your application is currently on.
As a result, the origin of the cookies is set correctly to the domain you run
the app on instead of
This behavior is necessary to avoid issues with the browser CORS policy.
ory proxy to proxy traffic to the frontend application
ORY_SDK_URL=https://project-slug.projects.oryapis.com ory proxy http://127.0.0.1:3000
docker-compose up -d
npm run dev
http://127.0.0.1:4000 and click
Sign In or
Sign Up buttons
- Deploy frontend application to S3
- Deploy backend to AWS lambda
- Add Two Factor Authentication (2FA) to your App
- Add social signin features
- Configure more secure password policies
- Implement email and phone verification and account Activation