We realize most people read this page before even trying Encore, so we start with a perspective on how you might reason about adopting Encore. Read on to see what tools are available for migrating away.
Picking technologies for your project is an important decision. It's tricky because you don't know what the requirements are going to look like in the future. This uncertainty makes many teams opt for maximum flexibility, often without acknowledging this has a major negative impact on productivity.
When designing Encore, we've leaned on standardization to provide a well-integrated and incredibly productive development workflow. The design is based on the core team's experience building highly scalable distributed systems at Spotify and Google, complemented with loads of invaluable input from the developer community.
In practise this means Encore is opinionated in certain areas, enabling static analysis used to create Encore's application model. This is core to how Encore can provide its powerful features, like automatically instrumenting distributed tracing, and provisioning and managing cloud infrastructure.
Many software projects end up having some novel requirements, highly specific to the problem they're addressing. To accommodate for this Encore is designed to let you go outside of the mold when you need to, by letting you drop down in abstraction level.
We believe that adopting Encore is a low-risk decision for several reasons:
- There's no upfront work to get the benefits
- Encore apps are normal programs where less than 5% of the code is Encore-specific
- All infrastructure, and data, lives in your own account in AWS/GCP
- It's simple to integrate with "unsupported" cloud services and other systems
- Key parts are Open Source, including the parser, compiler, and runtime
If you want to migrate away, we want to ensure this is as smooth as possible! Here are some of the ways Encore is designed to keep your app portable, with minimized lock-in, and the tools provided to aid in migrating away.
Building with Encore doesn't require writing your application in an Encore-specific way. Encore applications are normal programs where less than 5% of the code is specific to Encore.
This means that the changes required to migrate away will be almost exactly the same work you would have needed to do if you hadn't used Encore in the first placem, e.g. writing infrastructure boilerplate. There's no added migration cost.
In practise, the code specific to Encore is limited to the use of Encore's Infrastructure SDK. So if you wish to stop using Encore, you need to rework these interfaces to function in a traditional way. This normally means adding boilerplate that isn't necessary when using Encore.
If you've decided to migrate away from Encore, Encore has built-in support for ejecting your application as a way of
removing the connection to Encore. Ejecting your app produces a standalone Docker image that can be
deployed anywhere you'd like. See
encore eject docker --help for more information.
To run your app as an ejected image it needs to be configured. This configuration is normally handled by Encore,
but needs to be manually managed when ejecting. Two environment variables need to be set:
ENCORE_APP_SECRETS provides the values of all of your application secrets. The value should be a comma-separated list
of key-value pairs, where the key is the secret name and the value is the secret value in base64 encoded form
(using Go's RawURLEncoding scheme). For example, if you had two secrets
Bar with the values
World respectively, the value of
ENCORE_APP_SECRETS should be
ENCORE_RUNTIME_CONFIG provides the runtime configuration Encore applications need. As the precise configuration changes
over time, please refer to the current runtime config definition. The app, environment, and deployment related information powers the encore.Meta API
and can be set to arbitrary values. The SQL database and SQL server information is used to configure how Encore connects to SQL databases,
and should be configured according to your infrastructure setup.
TraceEndpoint must both be left unspecified as they determine how the application communicates with Encore, and leaving them empty disables that functionality.
We're engineers ourselves and we understand the importance of not being constrained by a single technology.
We're working every single day on making it even easier to start, and stop, using Encore. If you have specific concerns, questions, or requirements, we'd love to hear from you!